Итоги 2015

Ну, что же, год закончен, значит надо подвести кое-какие итоги. Всегда было интересно, какие из заметок этого блога наиболее популярны. Вот ТОП-15 самых читаемых статей:

Полезные OID для получения информации о состоянии портов по SNMP
Проблема "конфликт hash" на сетевых коммутаторах
Последствия конфликта MAC-адресов
Перезагрузка коммутаторов по SNMP
Некоторые факты о диагностике кабеля
Сброс пароля и загрузочное меню
Планирование перезагрузки DES-3200-28/C1 по SNMP
Работа с конфигурацией и лог-файлами коммутатора по SNMP
Сохранение конфигурации коммутаторов по SNMP
Значения счетчиков ошибок
Разработка ACL для DES-3200-28/C1
Чтение информации о VLAN по SNMP
Примеры ACL для DES-3200-28/C1
Ingress Checking и LLDP
SWToolz - 5 лет!

Пусть статистика не совсем объективна, т.к. при подсчете не учитывалось "время жизни" статьи, но общие тенденции ясны. Можно выделить самые популярные темы:

• Поиск OID для самых разных случаев
• Проблема конфликта MAC-адресов
• Сброс пароля и получение доступа к коммутатору
• Перезагрузка и сохранение конфигурации по SNMP
• Примеры ACL для ревизии C1

Интересное получается наблюдение - чем проще задача, тем более востребовано ее решение. А вот QoS, извращения с ACL, автоматизация массовых операций и прочие хитрые трюки интересны значительно меньшему количеству читателей. Но посмотрим, что покажет следующий год. :)

p.s. Приятно видеть, что swtoolz таки попал в топ, пусть и на последнее место. Кстати, в следующем месяце он вернется к нам, правда уже в несколько ином качестве. :)

Дополнение к заметкам про QoS

За последние полгода понафлудил где мог своими соображениями насчет QoS в D-Link. Предыдущие заметки можно прочитать тут, тут и тут, а также на нескольких профильных форумах (пример). В связи с вновь открывшимися обстоятельствами я приблизился к просветлению еще на один шаг, и потому обновил свою заметку про QoS и iperf. Кому лень перечитывать, в нескольких словах суть такова:

• Iperf не способен забить канал также легко и непринужденно, как это делает торрент. Поэтому QoS надо проверять совместно с торрентом. Проще всего это сделать на MPEG TS, отлавливая нарушения последовательности continuity counter.
• На DGS-3100-24TG QoS работает как задумано, по крайней мере на небольших нагрузках. По умолчанию коммутатор "смотрит" на раскраску DSCP.
• На DES-3200-xx/C1 QoS также работает прекрасно. Есть некоторые интересные особенности, которые описал в конце статьи.

В общем, на данный момент со всем разобрались. Это радует. :)

Работа scheduling mechanism на разных моделях

Проверили на стенде работу scheduling mechanism. Результаты достаточно интересные. Если в двух словах, то настройки QoS позволяют распределять трафик по разным очередям (подробнее см. тут). Scheduling mechanism определяет, как коммутатор будет эти очереди опустошать:
При использовании строгого режима (Strict mode) обработки очередей пакеты из очереди высшего приоритета всегда обслуживаются первыми. Опустошение очередей происходит, строго следуя их приоритетам. Только тогда, когда очередь более высокого приоритета пуста, обслуживаются пакеты с более низким приоритетом.

В случае использовании взвешенного кругового режима обработки очередей (weighted round robin, WRR) количество пакетов, отправленное из каждой очереди, определяется присвоенным ей взвешенным коэффициентом.

Стенд представлял из себя ноутбук, подключенный на скорости 10 full к коммутатору DES-3200-28/B1, на который поступал мультикаст-поток с битрейтом больше 10 мбит/сек. Параллельно был запущен ping до ya.ru. Scheduling mechanism был настроен в режиме strict. Изображение в плеере ожидаемо рассыпалось, потери ICMP-пакетов составляли около 50%.

При переключении scheduling mechanism в режим weight_fair изображение по прежнему "разваливалось", но ICMP-пакеты теряться перестали.

Затем коммутатор был заменен на DES-3200-28/C1 и проведен тот же тест в тех же режимах. С остальными настройками по умолчанию при переходе из режима strict в режим weight_fair ничего не изменилось -  ICMP-пакеты по-прежнему терялись. Это говорит о том, что мы не до конца понимаем поведение ревизии C1. :)

Последним был проверен коммутатор DES-3028. В режиме strict он работает только для очереди с высшим приоритетом (3). Остальные очереди работают в режиме WRR. Коммутатор сообщаем нам об этом сам:
Note: The strict mode is only supported at the highest queue
and the other lower queues will still work at WRR mode.

Чем в теории это принципиально отличается от поведения на других моделях я затрудняюсь сказать, но на практике 100% трафика, не попавшего в очередь №3 было заблокировано. Ноутбук даже не смог разрешить имя ya.ru при помощи DNS. ICMP-пакеты не проходили совсем. При переключении scheduling mechanism в режим weight_fair поведение стало аналогичным DES-3200-28/B1.

В итоге в очередной раз видим, что к каждой железке нужен особый подход. Подумываю теперь чтобы включить режим WRR на моделях DES-3028 и DES-3200/B1.

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 (см. ссылку в начале статьи) также все прояснилось после тестов, где нагрузку создавал торрент-клиент. Поведение коммутатора вполне предсказуемое.