четверг, 11 мая 2017 г.

Группа D-Link Ru в Telegram

Про мессенджер Telegram слышали, наверное, все. И если простить ему привязку к телефонному номеру, то пользоваться им определенно можно. Групповые чаты достаточно удобны и используются многими сообществами, в том числе сетевыми инженерами.

Однако, после того, как уютненьком Nag.Ru начала преобладать "политота", все большую популярность стали набирать тематические сообщества со специфичной технической направленностью. И в самом деле, как можно обсуждать что-то важное, когда в интернете кто-то не прав? Так и появились Pro Telecom, Я люблю АС "Ревизор" и другие интересные группы.

Пожалуй, пришло время сделать группу для обсуждения оборудования D-Link Ru. Такая попытка уже предпринималась однажды, но успехом не увенчалась. Оно и понятно, ведь Jabber - день позавчерашний. Посмотрим, что получится в случае с Telegram.

p.s. Спамить группой не хочу. Интересно посмотреть как она будет наполняться сама по себе.

понедельник, 1 мая 2017 г.

DGS-3420-28SC Selective Q-in-Q

Тема сегодняшней заметки Selective Q-in-Q на DGS-3420-28SC. Модель коммутатора в данном случае не принципиальна, просто такой коммутатор есть под рукой и потому на стенде используем именно его.

Без лишних прелюдий обозначим задачу: завернуть несколько vlan с уровня доступа в одну общую vlan* на уровне агрегации, при этом протащив управляющую vlan транзитом.

Посмотрим на картинку:


На доступе у нас используется коммутатор DES-3200-28. В 1-м порту подключен клиент в vlan 444, а во втором - в vlan 555. Управляющий интерфейс коммутатора находится в vlan 7.

На агрегации используется коммутатор DGS-3420-28SC. Управляющий интерфейс также находится в vlan 7. На коммутаторе нет vlan 444 и 555, а вместо них есть общая vlan 101.

Таким образом, vlan 444 и 555, приходящие с уровня доступа, инкапсулируются в vlan 101 и отдаются в сеть через порт №28 коммутатора DGS-3420-28SC. И, наоборот, приходящий с сети трафик в vlan 101 разворачивается в vlan 444 и 555 соответственно и уходит через порт №20. Напомню, что Q-in-Q - это "двойное тегирование", т.е. за внешним тегом 101 идет внутренний тег (444 или 555) и коммутатор всегда может разобраться куда именно ему надо перенаправить трафик при "снятии" внешней метки.

Ладно, оставим теорию (о ней в другой раз) и перейдем непосредственно к настройкам.

ВНИМАНИЕ! При включении Q-in-Q все порты будут настроены как NNI и трафик от них пойдет с внешней меткой 0x88a8. Если вы этого не ожидали и не были к этому готовы, то доступ к коммутатору будет потерян. Поэтому, если на стыках с данным коммутатором вы используете "обычные" vlan 802.1q, то выполните следующую команду:

config qinq ports 1-28 outer_tpid 0x8100

После этого можно включить Q-in-Q без опасений потерять доступ:

enable qinq

Создадим "внешнюю" vlan и добавим ее на оба порта. Тут ничего сложного, все стандартно:

create vlan 101 tag 101
config vlan 101 add tagged 20,28

Создадим трансляции для каждой vlan уровня доступа. Здесь мы говорим коммутатору, какую клиентскую (cvid) vlan нужно поместить в какую провайдерскую (svid) vlan. В нашем примере мы помещаем vlan 444 и 555 в vlan 101:

create vlan_translation ports 20 add cvid 444 svid 101
create vlan_translation ports 20 add cvid 555 svid 101

Теперь нам надо позаботиться о том, чтобы не потерять управление коммутатором доступа. Мы предполагаем, что vlan 7 уже создана на обоих коммутаторах и добавлена на порты 20 и 28 коммутатора DGS-3420-28SC. Нам остается всего лишь сказать коммутатору, что клиентская vlan 7 не будет никуда заворачиваться, а будет "транслироваться" в vlan провайдера с номером... 7:

create vlan_translation ports 20 replace outer_vid 7 svid 7

Ну и, наконец, сменим роль порту №20 на UNI:

config qinq ports 20 role uni

После этого схема, изображенная на рисунке, станет рабочей.

P.S. Обратите внимание, что коммутатор доступа вообще никак не настраивается специально под Q-in-Q.

*Часто о VLAN говорят в мужском роде. Я же использую женский, т.к. VLAN - это "Виртуальная LAN". LAN - это сеть, "локалка", т.е. "она".

понедельник, 17 апреля 2017 г.

Тестирование DGS-3420-28SC на тему "конфликт hash"

Довольно долго у меня не было ни возможности ни повода для новой заметки. Теперь он появился). Назрела необходимость прогнать через DGS-3420-28SC большое число MAC-адресов и стало интересно, как железка справится с данной задачей. Отдельные посты на специализированных форумах заставили задуматься о проблеме hash и вопрос тестирования назрел сам собой.

Итак, в нашем тесте мы не будем флудить коммутатор сгенерированными MAC-адресами, мы поступим хитрее - затопим его реальными MAC'ами, взятыми с реальной железки. Получим от коллег по отрасли список MAC-адресов ("донором" выступил Brocade SX-800) и удалим дубликаты. В остатке получается список из 7466 уникальных адресов. Затем установим Ostinato и напишем скрипт для генерации трафика на Python. Этот скрипт использует simple-ostinato. В принципе, изначально я собирался использовать Scapy, но под Windows запустить его мне не так и удалось из-за различных зависимостей.

Когда все готово, подключаемся к коммутатору и заливаем туда все адреса, не забыв предварительно увеличить fdb aging_time. Минут через 10 проверяем результат.

Я просто оставлю здесь картинку и никак не буду ее комментировать. :)

пятница, 23 сентября 2016 г.

Сертификационная программа D-Link. Курс "Технологии коммутации и маршрутизации".

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

Описание курса


Курс "Технологии коммутации и маршрутизации современных сетей Ethernet" затрагивает следующие темы:
  1. Основы коммутации
  2. Начальная настройка коммутатора
  3. Виртуальные локальные сети (VLAN, GVRP, Q-in-Q, Traffic Segmentation)
  4. Функции повышения надежности и производительности (xSTP, LDB, LACP)
  5. Адресация сетевого уровня и маршрутизация
  6. Качество обслуживания (QoS)
  7. Функции обеспечения безопасности и ограничения доступа к сети (ACL, Port Security, 802.1x, Guest VLAN, Safeguard Engine)
  8. Многоадресная рассылка
  9. Функции управления коммутаторами (SIM, SNMP, RMON, Port Mirroring)
  10. Обзор коммутаторов D-Link
После прохождении каждой темы нужно сдать мини-тест из 5-7 вопросов. Следующая тема станет доступна только после прохождения теста без ошибок.

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

Пробного контрольного теста для данного курса нет, вместо этого выполняются лабораторные работы. Лабораторные работы можно получить у преподавателя или у регионального представителя D-Link. Для допуска к основному тесту нужно выполнить итоговую самостоятельную работу (Лабораторная работа №17). После успешной сдачи теста выдается сертификат.

Примечание: Лабораторные работы являются практическими и выполняются на реальном оборудовании. Таким образом, надо либо проходить обучение в авторизованном учебном центре D-Link, либо воспользоваться служебным положением и получить нужное оборудование на работе, в случае, если есть такая возможность. :)

Последовательность шагов для получения сертификата


Таким образом, процедура получения сертификата такова:
0. Регистрируется на образовательном портале D-Link.
1. Проходим курс «Основы сетевых технологий. Часть 1: Основы передачи и коммутации данных в компьютерных сетях» и получаем сертификат.
2. Самостоятельно регистрируемся на курс «Технологии коммутации и маршрутизации современных сетей Ethernet».
3. Изучаем учебный материал каждой темы и сдаем соответствующий мини-тест.
4. Получаем у преподавателя или представителя D-Link лабораторные работы.
5. Собираем стенд и выполняем лабораторную работу №17.
6. Отправляем преподавателю или представителю D-Link отчет о проделанной работе.
7. Получаем доступ к итоговому тесту и проходим его в офисе D-Link или в авторизованном учебном центре.
8. Получаем сертификат.

Как видно, все не так просто. Нужно либо иметь возможность пройти платное обучение в авторизованном учебном центре либо работать в соответствующей отрасли (например, ISP) и иметь контакты с региональным представительством D-Link. Таким образом, получение сертификата доступно не всем. Тем не менее, если у кого то нет возможности пройти всю цепочку шагов полностью, я рекомендую выполнить шаги 0, 2 и 3. То есть просто прочитать курс для себя.

Итоговая самостоятельная работа


Итоговая самостоятельная работа предполагает воссоздание в миниатюре полностью работоспособной сети из 10 единиц активного сетевого оборудования (1 маршрутизатор и 9 коммутаторов) и нескольких рабочих станций.

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

Используемое оборудование: Маршрутизатор DES-3810-28 и 8-9 коммутаторов DES-3200-28.

В работе будут использованы следующие протоколы и функции: VLAN, маршрутизация между VLAN, LACP, RSTP, 802.1p, ACL, LBD, Safeguard Engine.

В лабораторной работе предложена топология сети с резервированием и избыточными каналами связи. На каждый коммутатор доступа выделяется отдельная VLAN. Расположение устройств, сетевая адресация, идентификаторы VLAN, номера портов и прочие параметры выбираются самостоятельно. Также в работе указаны несколько заданий и ожидаемый результат их выполнения

Для тех кто работает с оборудованием D-Link на практике работа особой сложности не представляет. Но те, кто знаком в основном с теорией, могут испытывать затруднения. Как мне кажется, по большей части эти затруднения будут касаться RSTP и VLAN. Предлагаемая в работе топология сети состоит из нескольких колец и множества резервных каналов. Не запутаться в этом, правильно рассчитать роли портов и не потерять доступ к оборудованию в процессе настройки новичкам может быть сложно. К примеру, в лекциях не говорится о том, что ingress checking действует на BPDU-пакетики и что удаление VLAN с порта может разорвать дерево STP. Сложности могут быть и с незначительными отличиями в синтаксисе между разными ревизиями DES-3200. Что же касается VLAN, то тут надо просто предусмотреть целостность VLAN при разрыве магистралей и перестроении колец. На мой взгляд, необходимый для этого опыт можно получить из регулярной практики, а лекционного материала для решений таких вопросов недостаточно. Хотя, если такие моменты вопрос не вызывают, то в целом с работой проблем не будет. На работу нужно где то два дня времени - это начиная от сборки стенда и заканчивая оформлением отчета.

Экзамен


Экзамен становится доступным после успешной проверки преподавателем итоговой самостоятельной работы. Дата и время обговариваются заранее. Для активации теста потребуется пароль. На экзамен отводится 90 минут. Количество вопросов - 72. Проходной балл мне неизвестен, но он меньше 90%. :) Вопросы относятся к пройденным темам и в большинстве своем достаточно простые. Есть несколько вопросом по командам коммутаторов. Кто видит консоль первый десяток раз легко может там проколоться. Непосредственно перед экзаменом рекомендую заново пройти тесты в конце каждой главы - вопросы на эти темы будут на экзамене.

Некоторые выводы


Что можно сказать о курсе "Технологии коммутации и маршрутизации современных сетей Ethernet"?

1. Курс объективно сложнее CCNA. Если в CCNA основной упор идет на теорию, то в данном курсе на практику. К тому же некоторые темы отсутствуют в CCNA в принципе.
2. Курс сложнее зарубежного аналога D-Link Certified Specialist, но проще чем D-Link Certified Professional. Это можно видеть по перечню тем.
3. Сертификат D-Link получить сложнее, чем сертификат Cisco. Если в случае сдачи CCNA/CCNP можно подготовиться самостоятельно и потом просто прийти на экзамен, то в случае D-Link путь несколько более извилистый. :)
4. У D-Link Russia отличный учебный материал на русском. Мне он очень понравился.

Ну, на этом все. Устал уже писать. :)

четверг, 21 июля 2016 г.

Проблемы передачи трафика в стеке DGS-3000-28SC

В конце зимы я писал о проблемах стекирования DGS-3200-28SC при помощи неродного кабеля, а также о том, что с родным кабелем все хорошо. Однако только сказка быстро сказывается, а с закупками обычно совсем другая история. :) Поэтому на одном узле пришлось собрать стек с использованием первого кабеля. Я подобрал такую комбинацию, в которой стек загружался и собирался корректно, запустил узел и забыл о нем почти на 4 месяца. А затем что-то пошло не так.

Данный стек состоит из двух коммутаторов DGS-3000-28SC. На узел приходит 2 магистрали и каждая включена в свой коммутатор. То есть даже если стек развалится, то все устройства будут доступны автономно. Проблема, которая появилась в начале лета, заключалась в том, что мультикаст, приходящий по второй магистрали, попадал на первое устройство в стеке то ли с потерями, то ли с нарушениями последовательности кадров. В общем, клиенты видели по IPTV рассыпающуюся картинку чаще, чем этого бы хотелось. Переброска мультикаст-влана на первую магистраль вызвала аналогичные проблемы на втором устройстве. В общем причина была ясна - трафик передается между устройствами в стеке с повреждениями. Эта ситуация была временно купирована "распиливанием" мультикаст-влана на две части - абоненты первого коммутатора стали получать мультикаст, приходящий по первому линку, а абоненты второго - по второму. То есть мультикаст больше не передавался между устройствами через стыковочный кабель и проблема больше не наблюдалась.

Пока велась подготовка к ремонтным работам (работы нужно было провести ночью в будний день) проявилась уже другая проблема, практически во всем аналогичная первой, только на этот раз рассыпался уже уникаст. В ту же ночь на узел прибыла ремонтная бригада, которая долго и упорно пересобирала стек в различных комбинациях портов под присмотром администратора, параллельно мониторившего CC-ошибки в мультикаст потоке. Тесты показали, что перезагрузка, "подтыкание кабеля" и изменение стыковочных портов результатов не дают. А вот замена кабеля на "родной" ситуацию исправила сразу же - CC-ошибки обнаруживаться перестали. Мультикаст снова был запущен в одной влан в одном линке, т.е. все вернулось к исходному состоянию и с тех пор работает без нареканий.

Что послужило катализатором проблемы? Неизвестно. Возможно, это температура. У нас очень жарко этим летом. Как, впрочем, и любым другим летом. :)

P.S. Вопрос "кто виноват?" остается открыт. А вот "что делать" уже понятно. :)

вторник, 19 июля 2016 г.

DGS-3100-24TG и CPU


Случайно заметил, что загрузка CPU у древней модели DGS-3100-24TG различается в разных сетях управления. То есть просто переносим устройство из одной сети управления в другую и загрузка ощутимо изменяется.



На верхней картинке показан график загрузки CPU стека из трех DGS-3100-24TG. Этот стек используется для агрегации большого района. Когда всем коммутаторам (в т.ч. и 3100) в этом районе была изменена сеть управления, то нагрузка резко выросла вдвое. Что интересно, в старой сети управления ранее находился тот же самый набор коммутаторов. То есть ничего, кроме сети управления и VLAN, для них не изменилось. Но нагрузка выросла - чудеса! Тогда специально для 3100 организовал сеть /30 и CPU стал нагружаться слабее, чем в старой сети. Плюс к этому пропали всплески - график стал более ровным.

На нижней картинке похожие чудеса. Одиночный 3100 "перепрыгивает" из одной сети управления, где он к тому времени оставался один, в другую, где уже находится около 50 коммутаторов DES-3200-28. Нагрузка при этом падает на 30%.


Вот такая вот магия! Понятно, что для этого есть объективные причины, но найти их сходу я не смог. :)

четверг, 30 июня 2016 г.

Обновление Briseis

Последние несколько недель активно работал над усовершенствованием своих проектов. Сначала хотел поправить что-то одно, но, как это бывает, потянешь за ниточку и размотаешь целый клубок работы. В конечном итоге обновил всё по чуть чуть. Среди приятных изменений скрипт запуска под Linux для каждого из сервисов.

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

Что же именно поменялось в Briseis?

- Модели теперь определяются так же, как и в swtoolz-core
- Конфигурация теперь размещается в отдельных модулях, как у swtoolz-core
- Изменен принцип выбора набора метрик для каждой итерации
- Описание было существенно переработано

Что добавилось?

- Возможность отсылать метрики строго в одни и те же интервалы времени
- Возможность корректировать счетчики при обработке, что позволяет избежать всплесков на графиках
- Возможность выполнять walk-опросы раньше, чем set
- Возможность отправлять метрики на несколько серверов Graphite
- Возможность выполнять некоторые запросы без повторных попыток

Что это значит "на пальцах"?

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

Как этот сервис используется в моей сети?

На данный момент в моей сети установлено почти 3500 коммутаторов доступа, с которых каждые 5 минут считывается достаточно большое число параметров. Непосредственно сам опрос занимает 50 секунд и за это время с устройств собирается около 668 000 метрик. Часть из них (291к) уходит на один сервер Graphite для хранения, а другая часть (473к) - на другой, используемый для поиска аномалий (некоторые метрики отправляются на оба сервера). Данные на первом сервере неделю хранятся в оперативной памяти и используются дли отрисовки таких вот картинок:

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

Помимо этого программа через определенные интервалы времени сохраняет конфигурацию всех коммутаторов, а также отправляет команды на выгрузку конфигурации на TFTP-сервер. Причем для разных моделей конфигурация выгружается в разное время, чтобы не создавать DoS-атаку на сервер.

Все работает быстро и стабильно, а самая длинная операция укладывается в 5 минут. Программа настроена так, чтобы данные в Graphite поступали через равные интервалы независимо от того, выполнился ли опрос оборудования быстро или медленно (в случае, когда идет сохранение конфигурации).

P.S. Ответ на вопрос "Почему опять что-то самописное, а не %ваша_любимая_NMS%?" такой:
- Мне так удобно! :)

Система работает надежно и полностью автономно. Всю работу делают два демона на Python, изначально рассчитанные на достаточно высокую (для ISP) нагрузку. Никакой особой производительностью хост-машина обладать не должна. Производительная СУБД не требуется, диски не надрываются. Поэтому поводов менять что-либо в системе опроса доступа пока не вижу.