В коммутаторах Netgear есть поддержка 802.1p и DSCP. https://www.manualslib.com/manual/419422/Netgear-Gs728ts.html?page=183 Однако, когда у вас гигабитная магистраль, вы очень быстро перестанете испытывать какие-либо проблемы из-за того, что 802.1p или DSCP не используются. В большинстве случаев узким местом является канал на выход в интернет. Модем и удалённый роутер провайдера сами применяют QoS на линии. Я даже провёл тест: копировал файл со скоростью 110 МБ/с (мегабайт в секунду, не мегабит) по гигабитному соединению, которое одновременно использовалось для IPTV. IPTV при этом не пострадало совсем. Так что да, было бы неплохо, если бы это реализовали, но в большинстве случаев это не обязательно.

Но DSCP — это уровень 3? Значит, в коммутаторах UniFi и USG до сих пор нет QoS на основе DSCP? DSCP содержится в поле ToS заголовка IP, так что, теоретически, это уровень 3. Коммутаторы Cisco уровня 2 уже больше десяти лет умеют работать с DSCP и постепенно начали использовать его для внутренней очередности вместо COS, так что перекодировка DSCP в COS на коммутаторах второго уровня стала ненужной. То есть, хоть эти коммутаторы уровня 2 и не могли делать маршрутизацию (aka переключение на уровне 3), они могли принимать решения по очередям, глядя внутрь IP-заголовка и читая значения DSCP, а также изменять поле ToS.

Но так было не всегда. Старые коммутаторы Cisco уровня 2 не поддерживали DSCP, поэтому для доверительной границы и очередей там приходилось использовать COS.

Насколько я знаю, в коммутаторах UBNT UniFi QoS вообще отсутствует. QoS есть в коммутаторах UBNT Edge. Для меня это просто мозговзрыв. С другой стороны, когда у меня были клиенты, которые не хотели платить за сквозной дизайн QoS во всех частях сети, я советовал им отключать QoS в LAN полностью и сосредоточиться только на QoS в местах перегрузок — в основном, на выходе WAN каналов. Это срабатывало 99% случаев, так что QoS в LAN, по моему мнению, несколько переоценён. Правда, это справедливо только если LAN грамотно спроектирована с коммутаторами уровня 3. К сожалению, у UniFi до сих пор нет коммутаторов уровня 3, и где граница уровня 3 — только в USG (WAN роутер/фаервол). Такой плоский дизайн LAN значительно повышает шанс перегрузок, и тогда QoS в LAN становится действительно необходим.

Но у меня есть ощущение, что QoS в коммутаторы UniFi всё-таки придёт в этом году. Раз UBNT обновляет платформу UniFi VoIP в 2019, сложно представить, что они не думают про внедрение LAN QoS в коммутаторы UniFi.

Коммутаторы второго уровня других производителей могут изменять значения DSCP во входящих пакетах. То, что коммутаторы UBNT этого не умеют, — ещё одна причина, почему они предназначены для малого бизнеса. При этом QoS в LAN-коммутаторах сильно переоценён. Я занимаюсь корпоративными решениями Cisco R&S и VoIP уже 20 лет и очень редко видел реальную необходимость в QoS на уровне LAN. Тем не менее, возможность установить границу доверия на краю сети важна для обеспечения QoS в местах перегрузки (например, на интерфейсах WAN). Поэтому умение доверять и/или изменять DSCP-маркировку именно на пограничных коммутаторах второго уровня — важная функция для среднего и крупного бизнеса. Под «краем» я не имею в виду линейку оборудования Ubiquiti под названием «Edge».

@jeroenst

jeroenst, к твоему сведению, серия коммутаторов Ubiquiti EdgeSwitch действительно поддерживает QoS. Возможно, тебе удастся получить похожую статистику с помощью UNMS, хотя у меня пока не было времени это проверить.

Ну и ещё @Lanna у него радиостанции Airmax, которые из коробки уже работают с DSCP (если прошивка достаточно свежая).

И, как ты и сказал, QoS в локальной сети обычно переоценён и в большинстве случаев не нужен, поэтому я и сфокусировался именно на DSCP. Но, судя по всему, большинство его проблем были на шлюзе, и разобраться с ними было проще с чем-то другим, а не с USG — что меня нисколько не удивляет. К сожалению, в интерфейсе USG всё ещё много чего не хватает.

Это сообщение будет спорным, но вот мое мнение.

Я занимаюсь проектированием QoS для крупных предприятий уже десять лет. Специализируюсь на Cisco, поэтому все мои решения в основном связаны с Cisco, хотя немного работал и с коммутаторами HP. Раньше у Cisco была разрозненная система QoS для каждого типа коммутаторов, и QoS был крайне сложным даже в бюджетных моделях. В более дорогих коммутаторах, таких как Catalyst 6500 (сейчас снят с производства, но когда-то был флагманом Cisco для корпоративного ядра), QoS становился безумно сложным: у каждого типа платы своя модель QoS, порты на одной плате могли иметь разные модели, у Supervisors — свои, и так далее. Создать единый сквозной дизайн QoS в сети Cisco с множеством разных моделей коммутаторов — это огромная задача.

Сейчас Cisco пытается стандартизировать QoS на коммутаторах, основываясь на модели MQC QoS для маршрутизаторов (Modular QoS CLI). Новые коммутаторы, такие как 3850, уже используют модель QoS, очень похожую на модель маршрутизаторов Cisco. Как только Cisco полностью заменит все свои «старые» платформы коммутаторов, включая 3750X и 2960X, скорее всего будет единая модель QoS для всех типов, что значительно упростит жизнь.

Теперь к главному. QoS в LAN переоценен. QoS важен только при наличии перегрузки на канале. Раньше, на старых WAN-соединениях, надо было учитывать задержку сериализации, которая обрабатывалась QoS, но эта задержка становится незначительной, когда пропускная способность канала превышает скорость T1. Так что с современными LAN, особенно когда гигбитные порты уже стандарт для доступа, QoS на портах доступа чаще всего никак не влияет, даже в корпоративных сетях. В сегменте SMB QoS на портах доступа, скорее всего, никогда не включится, даже если его настроить. Если пропускная способность ядра коммутаторов хотя бы 10 Гбит/с или выше, перегрузка на ядре практически невозможна (при условии, что бэкплейн коммутатора способен обрабатывать такой поток на этих скоростях). Поэтому даже в SMB-сегменте, на ядре коммутаторов, перегрузка, скорее всего, не случится.

QoS действительно важен в WAN-линках, где пропускная способность существенно ниже, чем у ядра LAN. В WAN скорее всего возникнут перегрузки, и именно там маршрутизатор будет сбрасывать пакеты в очередях или начинать буферизацию из-за ограничений канала. QoS надо настраивать на WAN-маршрутизаторах, и в 99,99999% случаев этого достаточно для SMB-сегмента. Даже в корпоративных сетях QoS на LAN-коммутаторах вряд ли будет иметь значение при условии, что ядро коммутатора обладает достаточной пропускной способностью. Это можно долго обсуждать для крупных предприятий, но для SMB-сегмента, где используется техника UBNT, это без сомнения так.

Пожалуйста, сохраните это в секрете, потому что брать сотни часов за разработку сквозной политики QoS — очень прибыльный бизнес.

Но сначала я бы посмотрел в документацию ваших VOIP-клиентов, чтобы понять, можно ли там настроить DSCP. Какие у вас VOIP-клиенты? Специализированное оборудование? Программа на компьютере?

Все мои телефоны настроены с expedited forwarding (46) и приоритетом VLAN, установленным на 6. Я использую собственный сервер Asterisk с большим количеством ресурсов. В общем, я решил эту проблему, см. ниже. Спасибо, что нашли время прокомментировать, я очень ценю это.

Есть две вещи, которых я ждал на платформе Unifi. Во-первых, возможность настроить маршрутизацию на основе политики, чтобы различать трафик, идущий на WAN1 или WAN2. В графическом интерфейсе такой опции нет, и не получилось настроить через командную строку по инструкции для EdgeMax. Я сдался. Во-вторых, мне нужен более продвинутый QoS в графическом интерфейсе, как и вам, но его появление слишком затягивается. Мое решение — положить USG в ящик и поставить вместо него Draytek Vigor 2925. Draytek’и немного устаревшие, но очень, очень мощные роутеры. Я тонко настроил приоритеты, и мои проблемы с VoIP исчезли. Также я смог правильно маршрутизировать VoIP-трафик через VLAN, предоставляемый провайдером, чего я не мог понять с USG.

DSCP должен задаваться вашим VOIP-клиентом. И да, это такой «штуковина на втором уровне» 😀, но Airmax на это обращает внимание, и даже на новом ПО — внутри VLAN.

Та статья по устранению неполадок, которую я прислал, показывала захват трафика в Wireshark, где видно поле DSCP в пакете — это самый точный способ проверить, используется ли DSCP в вашей сети.

Но сначала я бы посмотрел документацию по вашим VOIP-клиентам — есть ли там возможность настроить DSCP. Какие у вас VOIP-клиенты? Специальное оборудование? Программа на компьютере?

Я бы начал с твоих связей, так как радиостанции Airmax, скорее всего, являются основными узкими местами в твоей сети. К счастью, в Airmax по умолчанию включено некоторое QoS. Я бы проверил, правильно ли твои VOIP-клиенты устанавливают значение в поле DSCP. Вот отличная статья по тестированию. Если это значение не задано, но может быть, или задано не так, как ожидает Airmax, это может стать для тебя быстрым и простым решением (надеюсь!).

Тебе не обязательно включать QoS везде. Это похоже на старую шутку: чтобы убежать от медведя в лесу, не нужно бегать быстрее медведя, нужно бегать быстрее самого медленного человека рядом со мной 😀

Я думал, что с помощью VLAN тоже можно настраивать QoS, но всё, что я нашёл, — это заметки о том, что в старых версиях прошивки Airmax были ошибки, из-за которых поле DSCP игнорировалось для трафика с VLAN-тегами. Так что, если ты давно не обновлял прошивку Airmax, самое время это сделать!