Да предположим, че получавате вашия трафик от 2 vlan-a, 1 за българския и 1 за международния трафик.
Правите следното нещо за да маркирате пакетите:

С тази команда току що сложихте ToS(0×0) за българския и ToS(0xb8) за международния.
Вие пускате на вашият клиент български и международен по 1 vlan, но не знаете как да разграничите скоростите? Ето един лесен вариант:

Това е само за даунлинк трафика, можете да шейпнете ъплинк трафика на клиента по същия начин, но използвайки ingress( аз не маркирам международен и ползвам общ ъплинк шейп)

Така вашият клиент вече не може да се възползва от по-ниския ви межународен трафик

Ето вариант да следите колко български и международен прави рисувайки проста графика:
Добавяме следните таблици:

По този начин виждате колко бг и международен трафик прави вашият клиент и със помощта на туулове като rrdtool/mrtg можете да го следите.

Надявам се да съм бил полезен.

Послепис: По този начин можете да маркирате не само български/международен, но и всякакъв трафик:

—-
Маркиране на локалния трафик и просто добавяте следния ред в шейп скрипта:

Линкове:

• Добромир Галинов Добрев

Статията има за цел накратко да обясня HTB, като използвам следният източник: HTB home.

HTB е йерархична споделяща трафик верижна дисциплина.

Концептуално, тя представлява условен набор от признаци, които са подредени в сетове с йерархична структура. Основната верижна дисциплина на всяко мрежово устройство (интерфейс) се нарича главна верижна дисциплина, или root qdisc. Тази главна дисциплина съдържа един клас (комплексните сценарии могат да имат множество класове, закачени към root qdisc). Този НТВ клас съдържа два основни параметъра:

- rate – гарантирания мрежов трафик, възможен за класа;
– ceil – максималния трафик, който класа може да консумира.

Тези параметри се задават от клас с по-висока йерархия и действат като граници на подкласовете. Стойностите rate и ceil може да не са еднакви за подкласовете в една верига, те може да не консумират целия определен за веригата трафик, но техния сбор не трябва да превишава общите за веригата граници. Това позволява запазване на част от общия за класа трафик за определен подклас, или с други думи, по-добър контрол на подкласовете.

Характеристиките на НТВ са следните:

1. Споделяне на връзката

HTB осигурява набор от услуги за всеки един клас, който включва минималния брой заявени и определени за класа услуги. Когато даден клас иска по-малко от определеният му трафик, излишъка се предоставя на друг клас, който иска услугата.

Командата за задаване на root класа към съответния интерфейс е следната:

Тази команда закача верижния ред (qdisc) на HTB за интерфейс eth0 и му задава „handle 1”. Това е име, или индентификатор, към който ще се обръщат командите по-долу. „default 12” означава, че всеки трафик, който не е класифициран, ще бъде възложен на този клас 1:12.

Обичайно handle се записват във формат x:y, където x е целочислен индентификатор за qdisс-а, а “у” е целочислен индентификатор на клас принадлежащ към този qdisc. Стойността на “y” трябва да бъде 0, когато е за handle на qdisc, а когато е за клас, трябва да бъде различно от 0. Напр., ако на потребител А се зададе 30kbps за www трансфер и 10kbps за всичко останало, а на потребител Б се зададат общо 60kbps, то командите са както следва:

Първият ред създава кореният (root) клас, 1:1 под реда (qdisc) 1:. Дефиницията на кореният клас е едно с htb qdisc като parent. Parent класa, както и останалите класове под НТВ qdisc, позволява на подкласовете си да взимат един от друг, но само parent класa не може да взима от друг. Могат да бъдат създадени други три класа директно под НТВ qdsic, но в този случай допълнителния (излишъка) трафик няма да бъде достъпен за останалите. За да се осъществи споделянето, трябва да се създаде допълнителен клас, който да служи като руут за останалите класове, които носят реалната информация под него.

Също така, трябва да се опишат пакетите, принадлежащи към всеки един клас.

Така клас А се идентифицира с неговото IP, което е представено с 1.2.3.4. Когато не е зададен филтър за клас 1:12, всеки трафик, който не е обхванат от описаните вече правила, ще се насочи към него.
Единственото, което следва да се допълни, е да се закачи верижния ред (qdisc) за съответния интерфейс и да се зададе идентификатор, към който командите ще се обръщат, както следва:

Важно е да се отбележи, че когато повече класове искат да заемат трафик, на всеки от тях се дава определен брой байтове, преди да бъде обслужен друг конкурентен клас. Този брой се нарича quantum (сума). Ако няколко класа се съревновават за общия трафик, те го получават според съотношението на техните суми. Също така, за прецизна обработка на сумите, те трябва да бъдат възможно най-малки и по-големи от MTU.

Обикновено не се налага сумите да се задават ръчно, тъй като НТВ избира предварително изчислени стойности. Изчисляват се класовите суми (когато ги добавяме или променяме), като тяхната норма се разделя на общия параметър r2q. По подразбиране стойността му е 10 и, тъй като обикновено MTU е 1500, тази стойност е подходяща за норми от 15 kBps (120 kbit). За по-малки от минималните норми при създаването на qdisc се определя r2q 1 (добре е да е от 12 kbit). Ако се наложи, при промяна или вмъкване на клас, може ръчно да се зададе сума. Когато се определя сума от командния ред, r2q за този клас се игнорира.

2. Йерархично споделяне

Както по-горе бе казано, услугите, предназначени за всеки клас са поне минимума от предвидените и заявените от тях услуги. Това се отнася за htb класове, които не са основи за други htb класове. За htb класовете, които са основни за други, наричащи се вътрешни класове, правилото е, че услугите, предназначени за всеки клас са поне минимума от предвидените за тях и заявените от техните подкласове услуги.

Според примера, даден по-горе, ако за клиент А е предвиден общ трафик от 40 kbps и www трафик от 30 kbps, излишъкът ще бъде пренасочен към останалия му трафик (ако има заявка), поне докато сумата достигне 40kbps.

В този случай, клиент А се представя със собствен основен клас, т.е.:

3. Burst (отклонение)

Има два вида burst – burst, и cburst. Burst е сумата на байтовете, с която qdisc може да увеличи скоростта си (rate), докато cburst е сумата на байтовете за увеличаване на тавана (ceil).
Мрежовият хардуер може да изпраща само по един пакет (в даден момент) едновременно със скорост, зависеща от хардуера. Софтуерът за споделяне на връзката може да използва тази особеност единствено, за да (приравни) симулира ефектите на няколко връзки, протичащи с различна (по-ниска) скорост. Ето защо скоростта и таванът в действителност не са измерени за даден момент, а са средноаритметични стойности, получени при измерване на множество изпратени пакети за определено време. Това, което в действителност се случва е, че трафикът от един клас се изпраща по няколко пакета едновременно с максималната скорост и след това за малко се обслужват останалите класове. Параметрите burst и cburst контролират количеството данни, което може да бъде изпратено с максимална (хардуерна) скорост, без да се опит да се обслужи друг клас.

Ако cburst е по-малък (в идеалния случай с големина един пакет), той формира bursts, които не превишават тавана на скоростта.

При задаване на стойност на burst за основен клас, по-малка от стойността за някой подклас, трябва да се очаква burst-а на основния клас да спира в някои моменти (защото подкласът ще източва повече отколкото основния клас може да обработи). НТВ ще запомня тези негативни burst-ове до 1 минута.
Ако се борави с високи скорости на компютър с ниска резолюция на таймера, ще трябва да се настроят минимални burst и cburst за всички класове. Резолюцията на таймера на системи i386 е 10ms и 1ms на Алфа. Минималният burst може да бъде изчислен като максималната скорост умножена по резолюцията на таймера. Така за 10Mbit на стандартен i386, се нуждаете от burst 12kb.

Aкo се зададе твърде малък burst, получаваната скорост ще бъде по-малка от тази, която е зададена. Най-новият tc tool ще изчисли и настрои възможно най-малкия burst, ако той не е зададен.

4. Приоритизиране на споделянето на трафика

При приоритизирането на трафика могат да възникнат два проблема. Първият засяга начинът, по който излишния трафик се разпределя между родствени класове. Правилото гласи, че излишният трафик се предлага първо на класове с по-висок приоритет. Но все още важат правилата за гарантираната скорост и за тавана.

Вторият е общото забавяне на пакета. То е сравнително трудно за измерване при етернет, който е прекалено бърз (забавянето е пренебрежимо). Но има лесен начин за преодоляването му. Може да се добави обикновен HTB с един клас, ограничаващ скоростта до 100 kbps и втори НТВ (този, който се измерва) като подклас.

Подходът, който решава описаните проблеми, се изразява в приоритизране на типа на трафика. Например, видео или аудио-трафик (при които е необходима точна скорост, за да не се спре трафика на другите класове) или интерактивен (telnet, SSH) трафик, който няма да засегне негативно други потоци.

Универсален метод е да се приоритизира ICMP, за да се получат ниски забавяния при ping, дори при пълна употреба на връзките.

Stochastic Fairness Queuing – Стохастичното безпристрастно подреждане (SFQ) принадлежи към семейството на верижните дисциплини, основаващи се на „справедлив” алгоритъм на подреждане. Този алгоритъм е предложен от Джон Негъл през 1987г. Според подхода на Чък [11], тази дисциплина може да бъде обяснена по следния начин:
Безпристрастното подреждане (Fair queuing) е основата на един клас дисциплини за верижно класифициране, проектирани така, че да подсигурят на всеки клас равен достъп до мрежовите ресурси и да предотвратят завишаване консумацията от страна на засилен изходящ трафик. В FQ пакетите първо се класифицират от системата като потоци, а след това се отнасят към опашка, която специално е обвързана с този поток. След това опашките се обслужват пакет по пакет в циркулираща верига. Празните опашки се пропускат.
FQ се отнася и към поточните или поточно-базираните дисциплини

FQ наподобява няколко врати. След като един пакет пристигне, той се класифицира и предава през една от вратите. Вратата е вход към опашка, която се обслужва заедно с няколко други опашки пакет по пакет в кръгообразен ред. По този начин обслужването на всяка опашка се осъществява „справедливо”.
Ключът към класифицирането на един поток е диалогичен, което означава цифрово представяне, основаващо се на tuple [изходен адрес, изходен порт, целеви адрес]. По-усъвършенстваните изпълнения могат да използват „комплекта” [изходен адрес, изходен порт, целеви адрес, протокол] за класифициране. Тъй като не е целесъобразно да се използва само една опашка за всеки диалог, SFQ е сборен хеширащ алгоритъм, който разделя трафика на ограничен брой опашки. Според Ларц [7]:
Stochastic Fairness Queueing (SFQ) е проста реализация на семейството на справедливите верижни алгоритми. Тя е сравнително по-неточна, но изисква по-малко изчисления, бидейки почти идеално безпристрастна. Ключова дума в SFQ е диалог (или поток), която отговаря предимно на една TCP-сесия или на UDP-поток. Трафикът се разделя на доста голям брой FIFO-опашки, по една за всеки диалог. След това трафикът се изпраща в циркулация, „давайки възможност на всяка сесия да изпрати информация”. „Това води до справедливо поведение и не позволява на един диалог да заглуши останалите.” SFQ се нарича Стохастична, тъй като тя реално не разпределя опашките за всяка сесия, а разполага с алгоритъм, който разделя трафика на ограничен брой опашки, използвайки друг, сборен алгоритъм. Заради сбора, множество сесии могат да се окажат в една и съща „кофа”, което би разполовило всяка сесия, по този начин разполовявайки и наличната ефективна скорост. За да се предотврати осезателното появяване на подобна ситуация, SFQ често сменя сборния си алгоритъм така, че сблъсъкът на всеки две сесии да отнеме само няколко секунди. Важно е да се знае, че „SFQ е полезна само, в случай че релния изходящ трафик действително е пълен!” Ако не е, на линукс машината няма да има опашка и тя няма да има ефект. Затова е добре тя да се комбинира с други qdisc.

Тук трябва да се споменат някои концепции: първо, SFQ разпределя доста голям брой FIFO-опашки; както бе казано, не е целесъобразно да се използва само една опашка за всяка връзка или диалог. Въпреки това, максималното увеличаване броя на опашките помага на доброто действие на алгоритъма.
Тъй като броя на опашките обикновено е по-малък от броя на потоците, сборния механизъм се използва за приобщаване на потоците, според комплектното им представяне в опашките. Приобщаването е стохастично и налага използването на дислокализиращ механизъм за реконфигуриране на сборния алгоритъм, стремящ се към подобряване на разпределянето. Параметрите са прости. Според Ларц [7]:
SFQ е по-скоро самонастройваща се:
- Perturb
Реконфигурирането на сборния алгоритъм се прави еднократно. Ако това не бъде извършено, той не може да бъде реконфигуриран отново, което не е препоръчително. „10 секунди е една добра стойност.”
- Quantum
Количеството байтове в потока, на които е позволено да бъдат освободени от опашката преди да дойде ред на следващата опашка. По подразбиране, 1 максимално оразмерен пакет (MTU-оразмерен). „Настройката не бива да бъде по-малка от MTU!”

Конфигуриране:

Статитиката може да бъде разгледана с команда ‘tc show’:

– 800c: това е автоматично назначен номер за манипулация.
– Limit означава, че в тази опашка може да има 128 пакета.
- Могат да бъдат изчислени 1024 hashbucket-а, като 128 от тях могат да бъдат активни по едно и също време (в опашката не могат да влязат повече пакети).
- Веднъж на всеки 10 секунди сборния алгоритъм се реконфигурира.

Тъй като борави с множество опашки и потоци едновременно, и е в състояние да ги приведе в някакъв ред, SFQ може да бъде разглеждана като „дружелюбна”. Разбира се, ако по подразбиране разполагаме с PHB, много потоци се изплъзват. Тук се намесва SFQ. Ако реконфигурираме PRIO, например, имаме AF11 потока в клас 1:1, AF21 потока в клас 1:2, а останалите потоци (PHB, по подразбиране) са в клас 1:3. Използваме qdisc TBF, за да контролираме производителността на класове 1:1 и 1:2, както и qdisc SFQ – в клас 1:3. Първо, диаграмата:

А след това, конфигурационните команди:

Третата филтрираща команда гласи: всичко, което не съвпада, трябва да бъде пренасочено към клас 1:3, следващия с по-висок приоритет.

Priority queuing (PQ) е основата на клас алгоритми за верижно описване, създадени с цел да осигурят сравнително прост метод за поддръжка на диференцирани класове услуги. В класическата PQ пакетите първоначално се класифицират от системата и след това се добавят в диференцирани приоритизирани вериги. Пакетите се описват чрез основната част (head) на дадена веригаа, само ако всички вериги с по-висок приоритет са празни. В рамките на всяка приоритизирана верига, пакетите се описват в реда на FIFO

В Linux нещата са малко по-сложни. PRIO qdisc е класическа верижна дисциплина, която съдържа произволен брой класове с различен приоритет. При добавянето на пакет се избира суб-qdisc, определен от зададената в tc команда за филтриране. При създаването на нова верига PRIO, се създават три суб-верижни pfifo дисциплини. Всъщност, създават се 3 класа, именувани автоматично m:1, m:2 и m:3, където m е главния номер на верижната дисциплина. Всеки от тези класове се обединява с pfifo като отделен qdisc

Всеки път, когато трябва да се прибави пакет, той първоначално се насочва към клас :1. Когато той е празен, пакета се насочва към клас :2, а след това и към клас :3.

Тази дисциплина е много полезна за приоритизиране на определен трафик пред друг.
В tc тя има следните параметри:
- Връзки.
- Номер на създадените връзки. Всяка от тях е клас. Ако този номер се промени, трябва да бъде променена и prio-картата.
- Рrio-карта.
Ако за класифицирането на трафика не бъдат осигурени филтри, PRIO qdisc извлича информацията за неговото приоритизиране от TC_PRIO. Ядрото назначава на всеки пакет TC_PRIO – приоритет, основаващ се на TOS – флаговете или на предадените от приложението (socket options) опции.
TC_PRIO се определя и картографира от TOS, както следва:

Връзките са класове, именувани, по подразбиране, major:1 до major:3 така, че ако PRIO qdisc се именува 12:, tc филтрира трафика до 12:1 (връзка 0), за да гарантира приоритет. Това се повтаря като, връзка 0 става второстепенен (minor) номер 1, връзка 1 става второстепенен номер 2 и т.н.
Параметрите на рrio-картата сочат, че за да се създаде опашъчна дисциплина PRIO, трябва да бъдат създадени филтри, тъй като зададените по подразбиране параметри не са подходящи. Защо? За да бъде предпазен TOS. Настройките на PRIO qdisc, включващи използването на филтри са следните:

В посочената по-горе команда ръчно се задава номер 1:0 на PRIO qdisc (при използването на tc нулата може да бъде пропусната). Тъй като подреждането в PRIO е донякъде автоматизирано, тази команда съдава класове 1:1, 1:2 и 1:3, всеки от които съдържа инсталирана верига pfifо.
За задаването на филтри, към prio-класовете 1:1, 1:2 и 1:3 се назначават класове AF11, AF21 и AF31. Това означава:
AF11 = 1-2 = 001010
AF21 = 2-2 = 010010
AF31 = 3-2 = 011010
Това са шестте най-леви бита (кодови позиции DS); пълният TOS-байт ще съдържа два нулеви бита в дясно. В крайна сметка се получава:
AF11 = 00101000 = 0×28
AF21 = 01001000 = 0×48
AF31 = 01101000 = 0×68
Последното хексадесетично число се използва за създаването на филтри. Първия от тях е:

Обяснението на съдържанието на тази команда е, както следва:
– ‘tc filter add dev eth0′ – на утройство eth0 в tc се добавя филтър;
– ‘parent 1:0′ – източника на филтъра се идентифицира чрез номер 1:0 (или PRIO qdisc);
– ‘prio 1′ – този филтър има приоритет 1 (другите филтри ще имат, съответно, номера 2,3,4 и т.н., в този ред);
– ‘protocol ip’ – използва се IP протокол;
– ‘u32′ – конкретизира се вида на филтъра ;
– ‘match ip’ – тази част от командата задава на останалата й част да се съгласува с ip-хедера на пакета;
– ‘tos 0×28 0xff’ – указва отговарящите на класа tos-байтове (tc винаги умножава двете части: 0×28 * 0xff е равно на 0×28);
- ‘flowid 1:1′ означава, че потоците, отговарящи на този филтър, трябва да бъдат изпратени директно в класа, идентифициран с 1:1 (или клас PRIO 1:1).

Следващите две команди, с които се създава prio qdisc, са:

Предимствата на PRIO са:
- За софтуер-базирани рутери, в сравнение с по-усложнените верижни дисциплини, PQ осигурява на системата по-малко изчислително време.

- PQ позволява на рутерите да организират буфериралите пакети, като обслужва един клас трафик различно от други класове. Например, на приложенията в реално време, както и на интерактивния звук и картина, може да бъде зададен приоритет, пред приложения, които не оперират в реално време.

PQ има и известни ограничения:
- Ако количеството на трафика с висок приоритет не е зададено в периферията на мрежата, трафикът с по-нисък приоритет може да бъде забавен, докато приоритизирания бъде обслужен.

- Ако обема на трафика с най-висок приоритет стане много голям, трафикът с по-нисък приоритет може да бъде пропуснат, докато буферното пространство, назначено за този трафик се препълни. В този случай е възможно комбинацията от пропускане и пренасочване на пакети и увеличената латентност да доведе до пълна липса на трафик с по-нисък приоритет. Недопускащата изключения конфигурация на PQ може да съдаде мрежова среда, в която, докато цялата мрежа е ангажирана с обработката на трафика с най-висок приоритет, се доставя приоритизирана услуга с ограниченото качество.
- Неадекватното поведение на потока с най-висок приоритет може значително да допринесе за забавяне и прекъсване в другите потоци с висок приоритет, които споделят същата опашка.
- PQ не е решение на ограниченията на FIFO, където при претоварване UDP-потоците се обработват с предимство пред TCP-потоците. Ако на PQ се зададе по-висок приоритет на TCP-потоците, механизмите за управление на прозорците и трафика ще се опитат да употребят целия трафик на изходящия порт.
С оглед вземането на оптимални решения, е по-важно да се знаят предимствата и недостатъците на всяка дисциплина, отколкото командите за нейното конфигуриране. (за повече инфо: Stef Coene, www.docum.org )

FIFO (First­in, first­out) е най-елементарната дисциплина за опис на пакети.
При FIFO всички пакети се третират еднакво, като се подреждат в една опашка, и се обработват в същия ред, в който са присъединени към опашката. FIFO се отнася към First­come, first­served (FCFS)

FIFO е дисциплината, която Linux и повечето рутъри ползват по подразбиране. Ако qdisc не се зададе изрично, Linux инсталира интерфейсите си чрез нея.
Настройката на етърнет интерфеса чрез FIFO в Linux, се – осъществява чрез следния команден ред:

Съдържанието на тази команда е следното:
– ‘tc’ е съкратено от traffic control;
– ‘qdisc’ казва на tc, че се конфигурира верижна дисциплина (може да бъде ‘class’ или ‘filter’, ако се конфигурира клас или филтър);
– ‘add’ – добавяне на qdisc;
– ‘dev eth0′ – добавяне на qdisc към устройство, или интерфейс, Ethernet eth0;
– ‘root’, защото qdisc е за root (тази част не се изписва в pfifo за класовете, където съществува само root qdisc – там обаче се изисква да се нормализира използването на командата);
– ‘pfifo’ защото опашката се отнася до pfifo (packet-fifo).

pfifo изисква само един параметър: ‘limit’, който да укаже дължината на опашката (брой пакети, които опашката може да съдържа). В случая, пакетите са 10.

След създаването на опашъчната дисциплина, конфигурацията може да се провери със следната команда:

Като отговора ще бъде:

Командата изисква информация за вида qdisc на устройство eth0. tc отговаря, че qdisc е pfifo, номериран с 8001 (в действителност 8001:0): с лимит 10 пакета.

Верижните дисциплини и техните компоненти се номерират и идентифицират по-добре от 32-битово управление (handler), състоящо се от 16-битов основен и 16-битов второстепенен номер. Основния номер за опашките винаги е нула. При добавянето на опашката pfifo, управлението не бе означено и tc го създаде автоматично (8001:0).
FIFO има своите предимства и ограничения. Чък Шумерия изтъква следните предимства:
- за софтуер-базирани рутъри FIFO отнема много малко изчислително време на системата, в сравнение с по-сложните опашъчни дисциплини;
- поведението на FIFO е предсказуемо – пакетите не се пренареждат и максималното забавяне се определя от максималния капацитет на опашката. Докато той е малък, FIFO осигурява проста резолюционна поддръжка на мрежовите ресурси, без забавяне при всяко одбавяне.

FIFO има и следните ограничения:
- eдинична опашка FIFO не позволява на рутърите да организират буферираните пакети и след това да обслужат един клас трафик различно от другите класове.
- eдинична опашка FIFO влияе еднакво на всички потоци, защото незначителното забавяне на всички потоци се увеличава с увеличеното задръстване. В резултат на това, подреждането във FIFO може да причини забавяне, натовареност и загуба за real­time-приложенията (приложенията в реално време), минаващи през FIFO.
- в периоди на задръстване, FIFO дава предимство на UDP-потоците пред TCP. Загубата на пакети при задръстване в TCP –базираните приложения ограничава скоростта им на излъчване, докато UDP –базираните приложения не отбелязват загубата на пакети и продължават да излъчват с обичайната си скорост. Тъй като TCP –базираните приложения забавят скоростта си, за да се адаптират към променените условия на мрежата, забавянето във FIFO може да се увеличи, натовари и да ограничи количеството на изходящия трафик, консумиран от TCP –приложенията, които минават през опашката.
- натоварения трафик (трафик с burst) може да изземе цялото буферно пространство на FIFO, което води до отказ за обслужване на всички останали потоци до справяне с натоварването.