Маркирането на VPN порта не дава приоритет на гласовите разговори

Маркирането на UDP порта на VPN като високоприоритетен е най-честата промяна в QoS за глас и тя не отделя разговора от преноса на файлове, който споделя същия тунел. Двата потока излизат през един и същ криптиран сокет. Маркерът казва на следващия хоп, че всичко е еднакво важно, което е същото като да не му кажеш нищо. Разговора защитава доверена класификация преди криптирането плюс опашка, която наистина контролирате.

Тунелът скрива потока, който искахте да класифицирате

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

Стойност на DSCP, зададена от изходното приложение, оцелява само ако нещо я копира навън. OpenVPN 2.6 има passtos, документиран с обхват IPv4; IPsec прилага своя собствена политика за копиране или преобразуване на границата на тунела. Без тази стъпка външният пакет се маркира с каквато стойност по подразбиране използва интерфейсът на тунела, и опашката надолу по веригата така и не научава, че вътре има разговор.

Копираните маркери заслужават същото съмнение като всяка стойност, предоставена от клиента. Работна станция може да поиска ускорено препращане за задача за резервно копие, затова допускането и премаркирането на границата на доверие трябва да са в дизайна, преди маркерът да бъде повярван.

Приоритетът има значение само там, където се образува опашката

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

Справедливото опашковане и активното управление на опашки помагат дори без клас за глас, защото спират един обемен поток да запълни буфера. CAKE в Linux обединява оформяне, справедливост на поток и незадължителни класове Diffserv в един qdisc и внедреният мрежов мениджър трябва да притежава тази конфигурация, а не втора конкурентна настройка на опашка. Без оформяне клас, който превъзхожда обемния трафик, все още чака зад буфер, който вече е пълен.

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

Какво оцелява в публичния интернет

Архитектурата Diffserv описва обработката в административни домейни, поради което доставчик може да игнорира или пренапише маркер на граница. Обратното твърдение, че всяка мрежа винаги го премахва, е също толкова необосновано. Честният въпрос е какво точно този път е договорен и наблюдаван да прави. Проверете го с маркирана проба, вместо да повтаряте правило, което сте прочели някъде.

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

План за измерване, който изолира етапа

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

tc -s qdisc show dev eth0
tc -s class show dev eth0
mtr -rwzbc 50 voice.example.net

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