Подтверждаю такую же проблему у себя. До этого тестил с iperf, там такого результата нет. А когда попробовал с торрентом - тв сыпет и ничего сделать не могу.
Трафик покрашен по DSCP, но dscp trust на аплинке не влияет.

_________________
D-Link Switches: Tips & Tricks

Ну, в общем я разобрался. Судя по всему, на ревизии C1 каскадный мэппинг. Сначала идет мэппинг DSCP to 802.1p, а затем 802.1p to queues. То есть если у нас трафик покрашен только по DSCP, то нам сначала надо определить соответствующий ему CoS (show dscp map dscp_priority). После этого надо определить соответствие CoS определенной очереди (show 802.1p user_priority).

То есть если трафик красится только по DSCP, то команды такие:
0. config scheduling_mechanism strict (по желанию)
1. config dscp trust 28 state enable - доверяем на 28-м порту меткам ToS
2. show dscp map dscp_priority - проверяем приоритет CoS соответствующий нашему ToS. Допустим у нас DSCP 48, тогда по умолчанию "DSCP 48-55 is mapped to 6".
3. config 802.1p user_priority 6 6 - отправляем CoS (802.1p) 6 в очередь №6.

Все, мультикаст идет без ошибок! ACL не нужны.

_________________
D-Link Switches: Tips & Tricks

Но ведь это дефолтные настройки коммутатора. Из ваших 4 пунктов, только dscp trust на что-то должен повлиять, но, как я понял из сообщений выше, dscp trust не помогал. Может какой-то пункт пропущен?

Да, мне уже указали на NAG'е. Но в моем случае настройки были не дефолтными - их крутили и забыли вернуть. А TV при этом сыпалось. Вот здесь ТС тоже пишет, что у него настройки не по умолчанию.
В общем, при настройках по умолчанию проблем действительно не должно быть, но упомянутая особенность при этом имеет место - настройки 802.1p на C1 играют роль даже при DSCP покраске, а на B1, похоже что нет.

_________________
D-Link Switches: Tips & Tricks

Непонятно почему они не должны играть роль. Вопрос приоритетов: что важнее для коммутатора метка 802.1p или DSCP? Как поведёт себя коммутатор, если ему прилетает пакет с 802.1p = 7, а DSCP = CS4. Запихнётся пакет в самую высокоприоретную очередь на основе метки 802.1p или менее приоритетную на основе DSCP? Вопрос скорее к длинку и скорее всего останется без ответа, просто интересно.

Потому что там варианты "либо/либо". На B1 если предпочтение отдано IP DSCP, то настройки 802.1p не важны. По крайней мере так в моих тестах.
А в вашем примере два варианта для C1:
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.

_________________
D-Link Switches: Tips & Tricks

Да, понятно теперь. Но наводит на некоторые размышления.
Допустим, мы хотим, чтобы у абонента IPTV не сыпало, красим трафик на основе DSCP, вставляем туда 32 где-нибудь у источника и отправляем. Выставляем trust dscp на магистралях и трафик долетает до абонента по более-менее приоритетным очередям. IPTV не рассыпается, абонент доволен. Но вдруг абоненту попадётся например веб-сервер, который будет лить ему большой поток, при этом выставляя метку DSCP = 56? Этот веб-трафик начнёт попадать в высокоприоритетную 7 очередь и IPTV начнёт рассыпаться, причём не только у этого абонента, но возможно сразу у нескольких в цепочке до абонента. Получается, что если мы доверяем dscp, то они первоначально должны быть сброшены в ядре на 0.
А если два абонента льют трафик друг другу, минуя ядро? Значит надо сбрасывать DSCP ещё и на доступе.
По идее спас бы per-vlan-trust_dscp, но такого нет. А значит лучше уж красить трафик на основе 802.1p. Больше контроля.