суббота, 27 февраля 2016 г.

Проблемы стекирования DGS-3000-28SC

Приехали ко мне не так давно несколько DGS-3000-28SC, которые надо было объединить в стек. Стекируются эти устройства через два последних 10G-порта, а именно - через порты №27 и №28. Для соединения можно использовать модули SFP+ и оптические патчкорды, а можно воспользоваться готовым твинаксиальным кабелем. Для большего удобства прибегли ко второму варианту и приобрели вот этот кабель. И на стенде, внезапно, выяснилось, что стек может зависнуть в процессе загрузки. Вывести из этого состояния его можно только вручную разобрав стек. Я описывал эту ситуацию здесь.

Вот полное описание моих действий с устройствами "из коробки":
  1. Обновил прошивку до 5.03.B0004 и выполнил коммутаторам system reset
  2. Включил на коммутаторах stacking_mode. Они перезагрузились.
  3. Коммутатору с меньшим MAC назначил BoxID=1 и master force enable
  4. Коммутатору с большим MAC назначил BoxID=2
  5. Воткнул в ID1 стыковочный твинаксиальный кабель в 27-й порт
  6. Воткнул в ID2 стыковочный твинаксиальный кабель в 28-й порт
  7. Перезагрузил оба устройства
После этого стек мог зависнуть при сборке в процессе загрузки. Замена твинаксиального кабеля проблему не решала.

При другом сочетании портов проблема не возникала. При использовании варианта с двумя SFP+ и патчкордами все тоже было хорошо.

По рекомендации D-Link был приобретен их "родной" кабель - вот этот. С ним на стенде стек во всех ситуациях собрался и загрузился корректно.

Хорошо, с одной стороны, что проблема решилась. С другой стороны, раньше таких "нюансов" при работе с D-Link учитывать не приходилось. Да и заметил, вообще-то, совершенно случайно. Было бы очень грустно, если бы устройство, находящееся за десятки километров, перестало бы быть доступным после плановой перезагрузки. Будьте внимательны и не наступайте на мои грабли!

воскресенье, 31 января 2016 г.

swtoolz-core

В свое время swtoolz оказался полезным сервисом и мне давно хотелось вдохнуть в него новую жизнь, пересмотрев кое в чем прежний подход. На практике интерфейс скрипта часто переделывался пользователями и, поскольку, для меня это самая сложная часть, то в новом проекте я решил его вообще не делать. :) В итоге осталась только функциональная часть - неизменяемое ядро с внешними модулями конфигурации. Поэтому новый проект называется swtoolz-core и имеет следующие особенности:

  • Теперь это демон, работающий под FreeBSD (Linux в планах)
  • Для каждой модели устройства используется произвольный набор пользовательских операций Get/Walk/Set
  • В любой OID можно подставлять произвольное число пользовательских параметров
  • Сервис сам определяет модель устройства и находит соответствующий файл с настройками
  • Модели можно классифицировать как по sysDescr, так и по sysName
  • Изменение наборов OID для устройств не требует перезагрузки сервиса
  • Взаимодействие с сервисом осуществляется через API путем запроса соответствующего URL
  • Одним запросом к сервису можно выполнить несколько операций
  • Можно упаковывать несколько запросов в один пакет, как это сделано в Briseis
  • Результат опроса возвращается в json

Все это позволяет получить единый интерфейс с единым набором команд. К примеру, если мы вызываем команду enablePort с параметром 1 для конкретного IP, то сервис уже сам определяет что это за устройство и как конкретно для него выполнить "enable" для 1-го порта.

Аналогично дело обстоит и с операциями чтения. На странице приведены примеры некоторых OID для популярных моделей коммутаторов D-Link. Легко заметить, что, к примеру, административный статус порта для разных моделей определяется при помощи различных OID. С помощью swtoolz-core можно сделать общую команду, например walk_swL2PortCtrlAdminState, которая будет возвращать метрики для всей этой ветки и будет работать для любого коммутатора. Логика работы при этом такова:
  1. Первым запросом демон запрашивает sysDescr и sysName устройства, IP-адрес которого был передан ему в запросе
  2. Если ответ был получен, то согласно пользовательским настройкам выполняется классификация устройства
  3. Далее демон пытается подключить файл с настройками, соответствующий данному классу
  4. Из данного файла извлекается объект "walk_swL2PortCtrlAdminState" (в данном случае)
  5. Демон запускает отдельный поток где объект интерпретируется и в него помещаются пользовательские параметры (если заданы)
  6. Поток выполняет опрос устройства
  7. Результаты возвращаются пользователю в json

На данный момент swtoolz-core проходит внутреннее тестирование. С его помощью рассчитываю "научить" наш внутренний корпоративный сервис работать с моделями устройств, которые он ранее не подерживал.

четверг, 21 января 2016 г.

Сертификационная программа D-Link

О сертификационной программе Cisco не писал разве что только ленивый, в то время как об аналогичной программе D-Link практически ничего неизвестно. Не все даже знают, что такая программа вообще существует. Эта статья призвана заполнить существующий информационный вакуум, потеснив оттуда сферического коня.

Итак, существуют как минимум две сертификационные программы:
  1. Программа от D-Link Academy. На английском языке.
  2. Программа от Российского представительства D-Link. На русском языке.
Сертификационная программа от D-Link Academy состоит из трех уровней.


Начальный уровень (Entry Level)

Этот уровень содержит сертификационную программу DNA. Эта программа ориентирована на тех, кто только начинает свое знакомство с сетями. Данная программа знакомит с базовыми концепциями сетевых технологий.

Уровень специалиста (Specialist Level)

Это более продвинутый уровень, содержащий сертификационные программы DCS и DSS. Программа «Сертифицированный специалист D-Link» (DCS) совмещает теорию о сетях и лабораторные работы по конфигурации оборудования. В теоретической части рассматриваются такие темы как VLAN, STP и основы маршрутизации. Лабораторные работы позволяют участникам попрактиковаться в соответствующих темах. Курс «Сертифицированный специалист D-Link по продажам» (DCS) разработан для тех, кто хочет улучшить свои навыки в продажах и общении для завоевания потенциальных клиентов.

Уровень профессионала (Professional Level)

Программа «Сертифицированный профессионал D-Link» являтся высшим уровень сертификации. Она разработана для профессионалов в области сетевых технологий и для тех, кто уже обладает сертификатом DCS. После получения сертификата DCP участники расширяют свои познания по части развертывания сети, конфигурации, администрирования и устранения проблем.


По завершении программы участник получает соответствующий сертификат.

D-Link Network Assosicate:


D-Link Certified Specialist:


Изображения для D-Link Certified Professional нет, но удалось найти логотип:


Сертификационная программа российского представительства не пересекается с программой D-Link Academy.

В настоящее время доступны следующие учебные программы:
Обучение можно пройти в авторизованном учебном центре D-Link или дистанционно на образовательном портале. В случае самостоятельного изучения материала на портале дистанционного обучения, лабораторные работы, предусмотренные курсом, в любом случае нужно будет выполнить в авторизованном учебном центре или в ближайшем региональном офисе D-Link.

Экзамен на получение сертификата можно сдать в авторизованном учебном центре или в офисе D-Link. Чтобы получить сертификат нужно сдать следующие экзамены:
  1. Курс «Основы сетевых технологий. Часть 1: Основы передачи и коммутации данных в компьютерных сетях» - online-тест.
  2. Курс «Технологии коммутации и маршрутизации современных сетей Ethernet» - очный практический экзамен и online-тест.
  3. Курс «Основы сетевой безопасности. Часть 1: Межсетевые экраны» - очный практический экзамен (можно сдать только в учебном центре ВМК МГУ) и online-тест.
  4. Курс «Основы сетевой безопасности. Часть 2: Технологии туннелирование» - очный практический экзамен (можно сдать только в учебном центре ВМК МГУ) и online-тест.

Сертификат, выдаваемый по завершении курса «Технологии коммутации и маршрутизации современных сетей Ethernet»:

Сравнение сертификационных программ

Формально программа DCA могла бы соответствовать курсу «Основы сетевых технологий. Часть 1: Основы передачи и коммутации данных в компьютерных сетях», а DCS - курсу «Технологии коммутации и маршрутизации современных сетей Ethernet». Но, судя по затрагиваемым темам, DCS-Switching проще, чем соответствующий ему курс российского представительства D-Link. Аналогично можно предположить, что DCA проще курса основы сетевых технологий.

Если же сравнивать курсы российского представительства D-Link с курсами Cisco, то сравнение будет выглядеть примерно так:
  1. Курс Основы сетевых технологий соответствует сертификационной программе обучения CCENT и при этом несколько сложнее последней.
  2. Курс Технологии коммутации и маршрутизации современных сетей Ethernet соответствует программе CCNA и при этом также несколько сложнее.
При этом, если в первом курсе упор сделан на теоретическую часть, то во втором - на практическую.


Теоретический экзамен D-Link отличается от экзамена Cisco по многим параметрам:
  • Лекционный материал и сам экзамен разработаны в D-Link
  • Экзамен проходит в представительстве D-Link
  • Экзамен сдается на русском языке
  • Можно перемещаться по вопросам экзамена и отвечать в любом порядке
  • Частично правильные ответы тоже имеют определенный вес
  • Нет задач по конфигурированию оборудования. Они вынесены в практический экзамен, если он предусмотрен курсом.
  • Отсутствуют дампы вопросов и ответов :)

Подробности об экзамене "Основы сетевых технологий"

Отдельно можно рассказать про экзамен Основы сетевых технологий. Часть 1: Основы передачи и коммутации данных в компьютерных сетях.

Для сдачи этого экзамена не предъявляется каких-либо особых требований. Курс можно самостоятельно пройти в образовательном портале. Регистрация бесплатная и не требует подтверждения от D-Link. Курс содержит семь тем, после каждой из которых идет мини-тест на проверку знаний. Следующая тема станет доступной только после того, как вы ответите на все вопросы теста без ошибок. В случае неудачи тест можно пройти повторно через 2 часа.

Также в курсе предусмотрено семь лабораторных работ. Их можно не делать. :)

В конце обучения можно пройти пробный тест, состоящий из 60 вопросов. Проходной балл 80% или 85%, что соответствует оценкам 8 и 8,5. Повторно тест можно будет пройти через семь дней. Ни одного из этих вопросов не будет на экзамене, они нужны лишь для того, чтобы дать примерное представление о нем.

Сам экзамен также бесплатен. Для его активации нужно связаться с ближайшим региональным представительством D-Link, сообщить ФИО и e-mail, с которым вы зарегистрировались на портале, и договориться о времени проведения экзамена.

Экзамен состоит из примерно 100 вопросов, из которых вам будет предложено 72. Между ними можно свободно перемещаться и отвечать на них в любом порядке. Этим желательно воспользоваться, т.к. один вопрос может дать подсказку для другого. ;) На экзамен отводится 90 минут. Проходной балл такой же, как в пробном тесте. Напомню, что этот экзамен сдается в офисе D-Link.

Темы экзамена

Распределение вопросов по темам примерно следующее:
  • OSI - 25%
  • Введение в сетевые технологии - 20%
  • Физический уровень - 20%
  • Коммутация - 15%
  • Топологии сетей - 8%
  • IP-адресация - 6%
  • Остальное - 6%
Как видно, в основном рассматриваются физический и канальный уровень и некоторые общие вопросы.

Субъективные впечатления

Экзамен очень полезен! Не стоит относиться к нему как к чему то несерьезному - он достаточно сложен и размять мозги придется однозначно. Основная сложность это, конечно, огромный объем теоретического материала и вопросы экзамена, требующие знаний энциклопедического характера. Другая трудность - отсутствие информации об экзамене и курсах D-Link в сети Интернет. Если про CCENT/CCNA/CCNP написано много и даже встречаются сборники вопросов и ответов, то здесь придется идти на экзамен без этих ценных сведений. :) При всем этом и курс и экзамен однозначно проще CCNA и требует гораздо меньше времени для подготовки.

Я однозначно рекомендую подготовиться по данной программе и сдать экзамен. Некоторое расширение кругозора и новые впечатление обеспечены. :)

четверг, 31 декабря 2015 г.

Итоги 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 таки попал в топ, пусть и на последнее место. Кстати, в следующем месяце он вернется к нам, правда уже в несколько ином качестве. :)

четверг, 24 декабря 2015 г.

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

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


пятница, 11 декабря 2015 г.

Работа 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.

вторник, 1 декабря 2015 г.

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