QoS и iperf

На работе на стенде были проведены тесты QoS на коммутаторах DES-3200-28 старой и новой ревизии. Результаты достаточно странные. Но сначала пару слов о самом стенде. На коммутатор поступал мультикаст трафик с DSCP меткой 48 и в этом же направлении шел трафик, сгенерированный iperf. В порты последнего были включены потребитель мультикаста и хост, нагружающий канал паразитным трафиком. Иногда потребитель и второй хост находились за одним портом. Собственно, данные тесты явились продолжением вот этого эксперимента.

Схема примерно такая. Только в этот раз вместо DGS-3100 проверялись коммутаторы DES-3200-28.

Удалось выяснить вот что:
Для коммутатора DES-3200-28/B1 включение/отключение приоритизации сказывается на телевидении (мультикаст) самым непосредственным образом. Когда командой «config dscp_mapping dscp_value 48 class 0» мультикаст определялся в нулевую очередь, то трафик iperf попадал в очередь №1 (см. раздел "Advantages of QoS" в документации), т.е. имел приоритет над телевидением. В результате телевидение ожидаемо "рассыпалось", а TS Reader фиксировал ошибки CC.

Дополнительно было выяснено, то мэппинг трафика с помощью ACL отрабатывает раньше DSCP Mapping, то есть команда: «config dscp_mapping dscp_value 48 class 0» не играет роли, если ACL уже смэппил трафик в очередь, например вот таким профилем:
create access_profile ip destination_ip_mask 255.255.248.0 profile_id 7
config access_profile profile_id 7 add access_id auto_assign ip destination_ip 239.1.8.0 port [up] permit priority 6

Для коммутатора DES-3200-28/C1 все несколько сложнее. Даже при отключенной приоритизации мультикаст с iperf делят пропускную способность таким образом, что сначала проходит мультикаст*, а затем iperf. Незначительного числа ошибок в потоке удалось добиться только увеличением числа потоков iperf. Причем на другой рабочей станции это поведение не воспроизвелось.

Такое ощущение, что в этой модели приоритет мультикаста прописан "железно", а настройки QoS лишь слегка корректируют это. Возможно, этот вывод поспешен, но другого у меня нет. Буду рад любым идеям в комментариях.

*Добавлено 23.12.2015:
После того, как вместо iperf был задействован торрент-клиент, все встало на свои места. Мультикаст на DES-3200-28/C1 перестал проходить без ошибок, телевидение "посыпалось". Таким образом, мультикаст не имеет приоритета перед другим трафиком, просто данная модель обладает то ли большим буфером для данных, то ли более производительной коммутационной матрицей. В результате, в случаях, когда на коммутаторах старой ревизии ошибки уже есть, новая ревизия еще справляется с трафиком.

Про сам механизм QoS на DES-3200-28/C1 можно сказать что он работает как надо. Есть у него, правда, одна интересная особенность - настройки 802.1p на C1 играют роль даже при только DSCP покраске (без 802.1p). Если на ревизии B1 если предпочтение отдано IP DSCP, то настройки 802.1p не важны, но в случае C1 они тоже учитываются.

Поведение коммутатора при получении трафика с ToS (DSCP)=32 и CoS (802.1p)=7:
1. Если trust dscp выключен, то пакет полетит в очередь, определенную для CoS=7 в 802.1p user_priority. По умолчанию это 7-я очередь.
2. Если trust dscp включен, то на основе DSCP map dscp_priority определится CoS. В данном случае для DSCP 32-39 будет определен CoS, равный 4. Затем на основе 802.1p user_priority определится очередь, соответствующая CoS=4. В данном случае это 4-я очередь.

Иными словами, на C1 цепочка сопоставлений на 1 шаг длиннее:
DSCP-->CoS-->queue при включенном dscp trust и
CoS-->queue при выключенном.

А на B1 логика такая:
DSCP-->queue при включенном cos mapping ip dscp
CoS-->queue при выключенном ip dscp и включенном ethernet 802.1p.

P.S. С DGS-3100-24TG (см. ссылку в начале статьи) также все прояснилось после тестов, где нагрузку создавал торрент-клиент. Поведение коммутатора вполне предсказуемое.