FMdFFzVo/U6z6y4eQUEI/AAAAAAAAIpE/-4EaZTzNdUc/s1600/3.PNG' alt='Openwrt Qos Iptv' title='Openwrt Qos Iptv' />Миф о бесполезности Qo. S без перегрузки сети Хабрахабр. По работе я несколько раз сталкивался с мнением, что настраивать Qo. S в не перегруженной ethernet сети не нужно для успешного функционирования таких сервисов, как IPTV и Vo. IP. Это мнение стоило мне и моим коллегам многих нервных клеток и часов на диагностику фантомных проблем, поэтом постараюсь как можно проще рассказать о том, почему это мнение неверно. Меня зовут Владимир и я работаю сетевым инженером в одном из небольших ISP в Санкт Петербурге. Одним из оказываемых нами сервисов является L2. VPN под транспорт IPTV потоков. На примере этого сервиса я буду вести рассказ. Начинается вс с обращения в техподдержку от клиента оператора с жалобой на качество IPTV картинка сыпется артефакты, пропадает звук, в общем стандартный набор. IPTV у нас в сети классифицируется в очередь assured forwarding, поэтому диагностика заключается в том, чтобы пробежаться по железкам на маршруте и проверить, что в AF очереди на egress нет потерь, а на ingress нет физических ошибок. После этого мы бодро рапортуем клиенту, что в нашей зоне ответственности потерь не обнаружено, рекомендуем клиенту искать проблему у себя или поставщика IPTV, и идм пить чай с печеньем. Но клиент давит и продолжает настаивать, что виноваты мы, а у него вс отлично. Мы проверяем вс ещ раз, смотрим корректность классификаторов и маркировку пакетов от клиента, завязывается диалог и на каком то этапе задам вопрос а как у вас сконфигурирован Qo. S на сети, на что получаем ответ никак, у нас интерфейсы даже на 5. Qo. S не нужен. Тяжлый вздох и поехали. Обычно график загрузки на который все смотрят имеет интервал в 5 минут. Если real time то несколько секунд, начиная от 1. К сожалению и к счастью, современное сетевое оборудование оперирует периодами не в 5 минут и не в 1 секунду даже, а пикосекундами. То, что в течении секунды интерфейс не был загружен на 1. Эта прошивка основана на OpenWrt. Прошивка изначально имеет гибкие настройки QoS, поддержку квот, отображение статистики. Василина Ивановна Меняет Профессию Торрент тут. Ugtv5kFgmM/U6z5jevFyAI/AAAAAAAAIo0/UT4DYg6DvIg/s1600/1.PNG' alt='Openwrt Qos Iptv' title='Openwrt Qos Iptv' />Здесь мы приходим к концептуальному понятию микробрстmicroburst. Это такой очень короткий период времени, когда количество принимаемых устройством данных становится больше чем интерфейс способен отправить. Обычно первая реакция как так Мы же живм в эпоху скоростных интерфейсов Gbs уже обыденность, 4. Gbs внедряется повсеместно, а мы ждм уже 1. Tbs интерфейсы. На самом деле, чем выше скорость интерфейсов, тем жстче становятся микробрсты и их эффект на сеть. IPTV у нас в сети классифицируется в очередь assured forwarding. Потери пакетов есть, а QoS не настроен приоритетный трафик. Когда хост хочет начать получать широковещательный UDP трафик, то он должен принадлежать к группе UDP multicast group. В этой статье я расскажу о том как настроить сеть в OpenWRT. И ещ хотелось IPTV смотреть по WiFi. Механизм возникновения очень прост, я его рассмотрю на примере трх 1. Gbs интерфейсов, где трафик из двух из них уходит через третий. Это единственное необходимое условие для возникновения микробрста чтобы скорость входящих ingress интерфейсов превышала скорость исходящего egress интерфейса. Ничего не напоминает Это же традиционная схема уровня агрегации в ethernet сети множество портов ingress сливают трафик в один аплинк egress. Так строят сети абсолютно все от операторов связи до дата центров. У каждого egress интерфейса есть очередь отправки tx ring, которая представляет из себя кольцевой буфер. Туда складываются пакеты для отправки в сеть и конечно же этот буфер имеет конечный размер. Но у ingress интерфейсов на отправляющей стороне тоже есть такие же кольцевые буферы, которые обеспечивают такой же line rate. Что произойдт, если они начнут отправлять трафик одновременно У нашего egress интерфейса не хватит места в его tx ring, так как заполняться он будет в два раза быстрее, чем он способен отправлять пакеты. Оставшиеся пакеты нужно где то хранить. В общем случае это другой буфер, который мы называем очередью queue. Пока в tx ring нет места, пакет хранится в очереди и ждт свободного места в tx ring. Но вот беда у очереди память тоже конечна. Что произойдт, если ingress интерфейсы работают на line rate достаточно долго Память в очереди тоже закончится. В этом случае новому пакету уже негде храниться, и он будет отброшен такая ситуация называется tail drop. Сколько времени нужно, чтобы такой сценарий стал реальностью Давайте посчитаем. Самое сложное это найти мкость буфера интерфейса. Вендоры не очень активно публикуют такую информацию. Но возьмм, для примера, период в 2. Для 1. Gbs интерфейса нам потребуется 1. MB памяти. Сколько времени нужно работать на line rate двум 1. Gbs интерфейсам, чтобы полностью забить буфер Это время за которое передаются 2. MB со скоростью 1. Gbs. Да, ingress интерфейсов то у нас два, но egress интерфейс то тоже без дела не сидит и отправляет данные с той же скоростью, поэтому 2. Это сравнительно много. А 1. 0Gbs ingress интерфейсу сколько времени понадобится чтобы перегрузить 2. Gbs интерфейса Это уже ощутимо меньше. А сколько нужно памяти, чтобы хранить 2. Gbs интерфейса Это не то чтобы много по современным меркам, но ветер дует именно в эту сторону скорости растут, и чтобы сохранять глубину буфера требуется вс больше и больше памяти, что выливается в инженерные и экономические проблемы, а чем меньше буфер тем быстрее микробрст забьт его. Получается вечный вопрос для инженеров вендоров сколько памяти давать интерфейсу в железеМного дорого и каждая следующая миллисекунда становится бессмысленнее и бессмысленнее. Мало микробрсты будут приводить к большим потерям пакетов и жалобам от клиентов. Для других сценариев можете посчитать сами, но итог всегда один и тот же полностью забитая очередь и tail drops, а на графике полкой интерфейса и близко не пахнет, причм на любом периоде что в 5 минут, что в 1 секунду. Эта ситуация в пакетных сетях неизбежна интерфейс проработает на line rate меньше секунды, а потери уже будут. Единственный способ е избежать строить сеть так, чтобы ingress скорость никогда не превышала egress скорость, а это непрактично и нереально. Дальнейшая логика уже прослеживается и достаточно очевидна. Потери пакетов есть, а Qo. S не настроен приоритетный трафик никак не классифицируется и не отличается от другого трафика, и попадает в одну общую очередь, где он имеет равные шансы быть дропнутым. Что делать Настраивать Qo. S. Обязательно классифицировать приоритетный трафик и помещать его в отдельную очередь которой выделять б. Ольший объм памяти. Конфигурировать алгоритмы отправки пакетов так, чтобы приоритетные пакеты попадали в tx ring раньше других таким образом их очередь будет очищаться быстрее. Например, мы в своей практике используем следующий подход к очередям Assured forwardingAF подержи но доставь. В AF очередь классифицируется трафик, который требует гарантированной доставки, но не чувствителен к задержкам. Этой очереди выделен большой объм памяти, но датся сравнительно мало места в tx ring, и пакеты туда попадают позже других. Яркий пример такого трафика это IPTV он буферизиуется на клиентеVLC или STB, поэтому его можно задержать, но потеря превратится в артефакт изображения. Expedited forwardingEF доставь мгновенно или выброси. Этой очереди выделятся минимумили вообще никакой памяти для очереди, но выставляется высший приоритет для попадания в tx ring, чтобы пакет был отправлен как можно быстрее. Пример трафика Vo. IP. Голос нельзя доставить поздно, иначе и кодек телефонии не сможет его корректно собрать абонент услышит кваканье. В то же время потери отдельных пакетов на общем качестве голоса сильно не сказываются он у людей итак не идеальный. Есть ещ network controlNC и best effortBE, для управления сетью и всего остального соответственно, а трафик бывает ещ, например, телеконференции, который представляет из себя гибрид между Vo. IP и IPTV, но это уже совершенно отдельная тема, и настраивать Qo. S для них следует отдельно в каждой сети, в зависимости от топологии и прочих факторов. Вс вместе в целом это выглядит примерно таккартинка с сайта Cisco Надеюсь теперь вы будете настраивать Qo.