пятница, 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) нагрузку. Никакой особой производительностью хост-машина обладать не должна. Производительная СУБД не требуется, диски не надрываются. Поэтому поводов менять что-либо в системе опроса доступа пока не вижу.

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

PortViewer

Продолжая разговор об использовании swtoolz-core плавно переходим к проекту PortViewer. Это инструмент для быстрого и удобного получения информации о портах маршрутизаторов и коммутаторов. В нашей сети примерно 3500 коммутаторов D-Link различных моделей и ревизий. Биллинг "понимает" их и умеет с ними работать. Включить/выключить порт, отобразить состояние порта абонента, продиагностировать кабельную линию - все это можно сделать из системы отслеживания заявок. Однако, помимо коммутаторов доступа в сети имеется около 60 маршрутизаторов и коммутаторов агрегации. И вот с ними беда - разные вендоры, разные модели и модули и т.д. Система отслеживания заявок и биллинг с этими железками "не дружат." А, между тем, там тоже есть много портов, за которыми надо бы как то присматривать. Да, Zabbix всегда напомнит про "упавший" порт, но иногда хочется иметь более наглядную картину. Упал порт на какой то железке? Окей. А сколько у меня на ней вообще портов? В скольки модулях?  Сколько из этих портов должно работать? А сколько работает в данный момент? Сколько есть свободных портов в запасе? На эти вопросы проще всего ответить, имея перед глазами наглядную картину. И эту картину в нашей сети рисует PortViewer.

Казалось бы, а при чем здесь swtoolz-core? А на самом деле очень даже при чем. Несмотря на то, что PortViewer способен отрисовать состояния портов на нескольких десятках различных устройств, поддерживает он при этом, всего одну модель. Некое абстрактное сетевое устройство с заранее заданным набором свойств. Эти свойства описывают модули устройства, состояния портов и их количество. PortViewer запрашивает эти данные у swtoolz-core, после чего интерпретирует их по специальному алгоритму. Иными словами, для PortViewer нет разницы, работает ли он с устройством D-Link, Brocade, Cisco или Eltex. Главное - чтобы само устройство в принципе было способно отдать по SNMP требуемые данные, а также, чтобы для данной модели устройства у swtoolz-core был подготовлен соответствующий модуль. Таким образом, если хочется видеть состояния портов у какой то новой, экзотической железки, то ее нужно "добавлять" не в PortViewer, а в swtoolz-core. Вот такой вот симбиоз. Его преимущества очевидны. Во-первых, разработчику, проектирующему front-end, нет необходимости ломать голову над тем, как получить конкретный параметр с конкретной железки. А, во-вторых, администратор, отвечающий за back-end, не путается в ненужных ему алгоритмах. В данном случае он имеет дело только с конфигурационным файлом, содержащим списки параметров и OID.

Пора, пожалуй, завершить это уже несколько затянувшееся вступление и перейти, собственно, к демонстрации возможностей PortViewer. Поскольку автор на странице проекта не выложил никаких скриншотов, я сделаю это за него. (К сожалению, на этом движке картинки отображаются не очень красиво. Я не собираюсь с этим бороться, и оставляю это на совести Google.)

Рис 1. BigIron RX с 4 модулями по 4 порта. Развернуто выпадающее меню со списком узлов. Один узел раскрыт - можно видеть установленные там устройства и применить к ним одну из трех команд. Рамка вокруг портов 2/1, 3/3 и 3/4 говорит о включенном функционале flow control.

Рис 2. Автономный DGS-3100-24TG. Фон за номером порта указывает на тип порта: оранжевый - медный, голубой - оптический. Серый фон у всего порта говорит о том, что порт выключен административно.

Рис 3. DGS-3000-28SC, собранный в стек. Белый цвет у номера порта говорит о том, что фактическое состояние порта соответствует административному. Порт включен - линк поднят. Порт выключен - линка нет.

Кроме отображения портов PortViewer обладает еще несколькими полезными особенностями:
  • При наведении курсора на определенный порт можно посмотреть список vlan на этом порту.
  • Для Foundry кроме vlan будут отображены еще и ve и соответствующий IP-адрес.
  • Список vlan можно скачать в txt/csv форматах.
  • Каждая уникальная комбинация свойств портов (т.е. если что-то поменялось) записывается в базу данных. Эти уникальные "слепки" устройств потом можно просмотреть в любое время.
  • Благодаря кнопкам "telnet" из интерфейса удобно подключаться к устройству.
PortViewer - молодой проект. На данный момент в нем реализовано еще не все, что задумано. Тем не менее, уже сейчас это неплохой инструмент, помогающий в моей работе каждый день.

Использование swtoolz-core

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

Итак, как можно использовать swtoolz-core на практике? Рассмотрим здесь несколько примеров.

1. Изменить IP-адрес коммутатора D-Link. На практике это зачастую предполагает одновременное изменение еще и шлюза по умолчанию и управляющей vlan. Чтобы при этом не потерять управление устройством, нужно прибегать к некоторым хитростям. Например:
а) зайти на коммутатор с маршрутизатора, чтобы не потерять к нему доступ после изменения IP-адреса или шлюза по умолчанию
б) изменить IP-адрес через веб-интерфейс
в) использовать snmp-команды
г) использовать заранее подготовленные скрипты

Каждый из этих способов имеет свои недостатки. При подключении с маршрутизатора требуются лишние телодвижения, а внутренняя сессия "подвисает" когда у коммутатора меняется адрес. Веб-интерфейс зачастую отключен. SNMP-команды требуют умения ориентироваться в OID и MIB (swL2DevCtrlManagementVlanId относится к vendor-specific OID, т.е. отличается у каждой модели). Скрипты требуется готовить заранее и их может быть достаточно много (см. пример выше про уникальный OID для управляющей vlan).

Понятно, что один раз сменить адрес не является проблемой. Но если адреса надо поменять у нескольких десятков или даже сотен коммутаторов, то придется искать способ упростить эту операцию. На днях мне понадобилось изменить IP-адреса у 200 коммутаторов. Пришлось научить делать это swtoolz-core. В модуль для каждой модели был добавлен новый метод:
set_IpifCfg = [
#     .1.3.6.1.2.1.16.19.11.1.1                                         netConfigIPAddress
    ['.1.3.6.1.2.1.16.19.11.1.1', '5121', '{1}', 'IPADDR'],
#     .1.3.6.1.2.1.16.19.11.1.2                                         netConfigSubnetMask
    ['.1.3.6.1.2.1.16.19.11.1.2', '5121', '{2}', 'IPADDR'],
#     .1.3.6.1.2.1.16.19.12                                             netDefaultGateway
    ['.1.3.6.1.2.1.16.19.12', '0', '{3}', 'IPADDR'],
#     .1.3.6.1.4.1.171.11.113.5.1.2.1.2.16                              swL2DevCtrlManagementVlanId
    ['.1.3.6.1.4.1.171.11.113.5.1.2.1.2.16', '0', '{4}', 'INTEGER'],
    ]
После этого понадобилось лишь обратиться к API с нужными параметрами (выделены жирным) и дело сделано:

http://host.domain:7377/<user>/<device_ip>/<community_index>/set_IpifCfg/<IP>/<mask>/<gateway>/<mvlan>

2. Создать новую vlan. Выше уже было сказано, что новый IP-адрес зачастую предполагает новую vlan для управления. Создавать ее вручную не обязательно. Это можно сделать при помощи метода:
set_CreateVlan = [
#     .1.3.6.1.2.1.17.7.1.4.3.1.1                                       dot1qVlanStaticName
    ['.1.3.6.1.2.1.17.7.1.4.3.1.1', '{1}', '{2}', 'OCTETSTR'],
#     .1.3.6.1.2.1.17.7.1.4.3.1.2                                       dot1qVlanStaticEgressPorts
    ['.1.3.6.1.2.1.17.7.1.4.3.1.2', '{1}', '{3}', 'OCTETSTR'],
#     .1.3.6.1.2.1.17.7.1.4.3.1.5                                       dot1qVlanStaticRowStatus
    ['.1.3.6.1.2.1.17.7.1.4.3.1.5', '{1}', '4', 'INTEGER'],
    ]
Создание VLAN с ID 500, именем testvlan и member-портами 25-28:
/set_CreateVlan/500/testvlan/%f0

Поскольку в данном примере не используются vendor-specific OID, то данный метод будет работать для любого коммутатора D-Link.

3. Сохранить настройки коммутатора. Сохранение настроек - вещь важная и нужная. Да и делается легко:
set_SaveConfig = [
#     .1.3.6.1.4.1.171.12.1.2.18.4                                      agentBscFileSystemSaveCfg
    ['.1.3.6.1.4.1.171.12.1.2.18.4', '0', '2', 'INTEGER'],
    ]
Сама команда вызывается без параметров:
/set_SaveConfig
Примечание: в конфигурации swtoolz-core желательно убрать дополнительные попытки опроса (retries) для этого метода. Делается это просто:
no_retries = ['set_SaveConfig']
4. Изменить статус порта (включить/выключить). Для управления состоянием портов есть свой метод:
set_AdminStatus = [
#     .1.3.6.1.4.1.171.11.63.6.2.2.2.1.3                                swL2PortCtrlAdminState
    ['.1.3.6.1.4.1.171.11.63.6.2.2.2.1.3.%s', '100', '%s', 'INTEGER'],
    ]
Установить порт в состояние status:
/set_AdminStatus/<>/<status>
Сам список статусов можно получить так:
/AdminStatus

5. Изменить административную скорость порта. Для этого тоже есть свой метод:
set_AdminSpeed = [
#     .1.3.6.1.4.1.171.11.63.6.2.2.2.1.4                                swL2PortCtrlNwayState
    ['.1.3.6.1.4.1.171.11.63.6.2.2.2.1.4.%s', '100', '%s', 'INTEGER'],
    ]
Установить скорость speed для порта №:
/set_AdminSpeed/<>/<speed>
Список возможных вариантов доступен при вызове:
/AdminSpeed

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

Возвращаясь к теме изменения IP-адреса у 200 коммутаторов, можно подвести итог. Итак, сначала я сделал список соответствия старого и нового IP-адресов. После этого был написан простой скрипт, который вычислял адрес шлюза по умолчанию и подставлял этот и другие параметры в URL, примеры которых даны выше. Получившиеся ссылки сам же скрипт и вызывал. Первая ссылка содержала команду на создание управляющей vlan, вторая меняла DHCP Relay Remote ID, третья изменяла IP-адрес интерфейса, помещая последний в новую vlan, а четвертая сохраняла настройки. В итоге все коммутаторы (разных моделей и ревизий) были перенастроены довольно быстро, а главное - мне не пришлось заходить на каждый. :)

Здесь мы рассмотрели только snmpset-операции, как дающие заметный и понятный эффект. Выключили порт - он погас. Изменили IP-адрес коммутатора - и потеряли управление им он стал доступен по новому и т.д. Но если мы работаем с get/walk-операциями, то мы получаем, прежде всего, данные. И с этими данными надо что-то сделать. Об этом в следующей статье.

среда, 27 апреля 2016 г.

DGS-3100-24TG и trusted host

Коммутаторов DGS-3100-24TG в сети пока еще много и с их существованием приходится как то мириться. Наводя порядок в конфигурации заметил, что коммутатор может неадекватно вести себя при попытке изменить список trusted host. И вот сегодня снова столкнулся со странным поведением:

DGS-3100-Ol44-1p# show trusted_host

Management Stations

IP Address      Subnet Mask     Application
--------------- --------------- ---------------
10.100.100.0    255.255.254.0   all
10.90.90.0      255.255.255.0   all

Total Entries: 2

DGS-3100-Ol44-1p# delete trusted_host 10.90.90.0
No such entry in trusted hosts table.


То есть запись как бы есть и, в то же время, ее как бы нет. :) Добавил ее повторно, после чего получилось конкретно удалить.

Будьте внимательны при работе с этой капризной железкой - можно потерять доступ!