С Новым 2015 Годом!

Данная заметка 42-я по счету в нашем блоге. Число 42 - хорошее число. Не такое, конечно, как 48, но на многие вопросы по коммутаторам, SNMP и "всему такому" оно отвечает. :) При оформлении накопленного ранее опыта и отдельных разрозненных записей в статьи мне пришлось более глубоко вникнуть в некоторые моменты и вспомнить давно забытое. Поэтому, по крайней мере для меня, этот труд был проделан не зря. Однако, не исключаю, что мои записи окажутся полезными и кому то еще. :)

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

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

Всех с Новым Годом и пусть ваша стойка с оборудованием никогда не будет похожа на новогоднюю елку! :)

Примеры ACL для DES-3200-28/C1

В нашей сети много коммутаторов DES-3200-28/C1, но по ряду причин разработать ACL для них мы не успели. Тем не менее, работа в этом направлении ведется. Здесь я буду время от времени приводить некоторые примеры правил.

Update 2015.05.29: Добавлены несколько примеров.

#7 Профиль для разрешения любого трафика в определенных VLAN, а так же для абсолютных разрешений для конкретного порта
create access_profile profile_id 7 ethernet vlan 0xFF0 source_mac 00-00-00-00-00-00
config access_profile profile_id 7 add access_id auto_assign ethernet vlan_id   1 port all permit
config access_profile profile_id 7 add access_id auto_assign ethernet vlan_id  16 port all permit
config access_profile profile_id 7 add access_id auto_assign ethernet vlan_id 448 port all permit
config access_profile profile_id 7 add access_id auto_assign ethernet vlan_id 464 port all permit
config access_profile profile_id 7 add access_id auto_assign ethernet vlan_id 576 port all permit
#Чтобы разрешить любой трафик с порта X, добавьте следующее правило:
#config access_profile profile_id 7 add access_id auto_assign ethernet source_mac 00-00-00-00-00-00 port X permit


Ниже пример PCF-правил. PCF-профиль в данной серии может быть только один.

# Заблокировать Source IP  10.99.192.50 на 26-м порту
create access_profile profile_id 9 packet_content_mask offset_chunk_1 3 0xFFFF offset_chunk_2 7 0xFFFFFFFF offset_chunk_3 8 0xFFFFFFFF
config access_profile profile_id 9 add access_id auto_assign packet_content offset_chunk_3 0x0A63C032 port 26 deny


P.S. "Страничка в разработке". :)
Мне нужно решить кое-какие задачи, связанные с блокировкой нежелательного трафика на ревизии C1. Получившиеся ACL я затем приведу здесь.

Добавлено 2015.05.29:

Запретить vlan 3203 на порту 23:

create access_profile profile_id 4 profile_name pcf packet_content_mask offset_chunk_1 3 0xFFFF offset_chunk_2 4 0x0FFF0000
config access_profile profile_name pcf add access_id auto_assign packet_content offset_chunk_1 0x8100 offset_chunk_2 0x0C830000 port 23 deny

Внимание! На /C1 ревизии ACL PCF не видит метки 802.1q. Для блокировки трафика для определенного vlan на access портах надо использовать обычные ACL:

create access_profile profile_id 1 ethernet vlan 0xFFF
config access_profile profile_id 1 add access_id 2 ethernet vlan_id 3203 port 23 deny

Разрешить все тегированные фреймы:

config access_profile profile_name pcf add access_id auto_assign packet_content offset_chunk_1 0x8100 port all permit

Профиль для пропуска трафика в vlan 0-15, 16-31 и для безусловного разрешения трафика на порту X (закомментировано)

create access_profile profile_id 3 profile_name vip ethernet source_mac 00-00-00-00-00-00 vlan  0xFF0
config access_profile profile_name vip add access_id auto_assign ethernet vlan_id 1 port all permit
config access_profile profile_name vip add access_id auto_assign ethernet vlan_id 16 port all permit
#to manually allow any traffic for port X add following rule:
#config access_profile profile_name vip add access_id auto_assign ethernet source_mac 00-00-00-00-00-00 port X permit

В этом примере есть интересный нюанс.  Если кто его заметит, тогда прокомментирую. :)

На заметку: Правила для /C1 проверяются последовательно. Блокирующее правило PCF не перекрывает разрешающее ACL в другом профиле. На старых ревизии вроде как приоритет имело запрещающее правило.

Значения счетчиков ошибок

Не всегда понятно что может означать та или иная ошибка при передаче. Ниже моя попытка объяснить значение счетчиков ошибок, которые регистрирует коммутатор.

Счетчики ошибок при получении кадров (RX):

CRC Error

Counts otherwise valid packets that did not end on a byte (octet) boundary.

Счетчик ошибок контрольной суммы (CRC). В свою очередь, является суммой счетчиков Alignment Errors и FCS Errors.
FCS (Frame Check Sequence) Errors - ошибки в контрольной последовательности кадра. Счетчик регистрирует кадры с ошибками FCS, при этом кадры имеют корректный размер (от 64 до 1518 байт) и получены без ошибок кадрирования или коллизий.
Alignment Errors - ошибки выравнивания (некорректной длины кадра). Счетчик регистрирует кадры с ошибками FCS, при этом кадры имеют корректный размер (от 64 до 1518 байт), но были получены с ошибками кадрирования.
В случае, если кадр был классифицирован как имеющий ошибку Alignment Error, счетчик FCS при этом не увеличивается. Иными словами, инкрементируется либо счетчик FCS либо Aligment, но не оба сразу.

UnderSize

The number of packets detected that are less than the minimum permitted packets size of 64
bytes and have a good CRC. Undersize packets usually indicate collision fragments, a normal
network occurrence.

Счетчик кадров с правильной контрольной суммой и размером менее 64 байт. Такие кадры могут возникать в результате коллизий в сети.

OverSize

Counts valid packets received that were longer than 1518 octets and less than the
MAX_PKT_LEN. Internally, MAX_PKT_LEN is equal to 1536.

Счетчик кадров с правильной контрольной суммой, размер которых превышает 1518 байт, но не превышает 1536 байт - внутреннего максимального значения кадра.

Fragment

The number of packets less than 64 bytes with either bad framing or an invalid CRC. These
are normally the result of collisions.

Счетчик кадров с неправильной контрольной суммой или структурой кадра и размером менее 64 байт. Такие кадры могут возникать в результате коллизий в сети.

Jabber

Counts invalid packets received that were longer than 1518 octets and less than the
MAX_PKT_LEN. Internally, MAX_PKT_LEN is equal to 1536.

Счетчик кадров с неправильной контрольной суммой, размер которых превышает 1518 байт, но не превышает 1536 байт - внутренного максимального значения кадра.

Счетчик ошибок при отправке кадров (TX):

Excessive Deferrral

Counts the number of packets for which the first transmission attempt on a particular
interface was delayed because the medium was busy.

Счетчик кадров, первая попытка отправки которых было отложена из-за занятости среды передачи.

CRC Error

Counts otherwise valid packets that did not end on a byte (octet) boundary.

Счетчик ошибок контрольной суммы (CRC). На практике никогда не увеличивается.

Late Collision

Counts the number of times that a collision is detected later than 512 bit-times into the
transmission of a packet.

Счетчик случаев когда коллизия обнаруживалась после передачи первых 64 байт (512 бит) кадра.

Excessive Collision

Excessive Collisions. The number of packets for which transmission failed due to excessive
collisions.

Счетчик кадров, отправка которых не удалась из-за чрезмерного количества колизий.

Single Collision

Single Collision Frames. The number of successfully transmitted packets for which
transmission is inhibited by more than one collision.

Счетчик успешно отправленных кадров, передача которых вызвала более одной коллизии.

Collision

An estimate of the total number of collisions on this network segment.

Счетчик общего числа коллизий в сегменте сети.

Моно добавить, что на практике RX CRC обычно является результатом деградации среды передачи (медный кабель или оптоволокно), а TX-коллизии - результатом неправильного согласования скорости соединения, например half-линка.

Неплохая расшифровка значений счетчиков приведена тут.

SWToolz - 5 лет!

SWToolz - набор модулей для опроса коммутаторов D-Link, работающих под управлением простенького движка на PHP. Его задачей является вывод на одной странице всей важной информации о портах коммутатора. Наличие такой информации помогает быстро обнаружить аномалии на устройстве. Самым показательным в этом отношении является модуль 'ports', который можно наблюдать на картинке ниже.

Кроме 'ports' существуют еще модули 'vlan', 'fdb', 'impb' и 'pdesc'. Их назначение легко понять по названию. А можно просто посмотреть на подписи разделов в шапке на скриншоте выше.

SWToolz умеет работать с моделями DES-3026, DES-3028/G/P, DES-3526, DES-3200-28 и DGS-3100-24TG. На момент его написания еще не было DES-3200-28/B1 и DES-3200-28/C1, поэтому отображение информации для этих моделей может слегка отличаться от ожидаемого. :)

В двух словах, история этого продукта такова: В 2008 году понадобился инструмент для работы с коммутаторами. Все, что на тот момент имелось в распоряжении - это старенькая версия What's Up. Поэтому пришлось написать что-то свое. Первое решение было написано на Delphi и подключалось к коммутаторам по Telnet. Изначально была задумка назвать его switchinfo, но такое название слишкое длинное, а сокращенное - swinfo - попахивает свинством. Поэтому он был назван PortInfo. Некоторое время все шло хорошо, но довольно быстро выяснилось, что формат вывода команд в CLI довольно сильно меняется в прошивке от версии к версии. Это требовало постоянной правки кода. И это при том, что тогда в парке была всего одна модель - DES-3028. В результате проект родился заново, будучи написанным уже на PHP, а сам опрос коммутаторов производился по SNMP.

Ровно 5 лет назад, 25 декабря 2009 он был выложен в открытый доступ на официальном форуме D-Link

В 2010 мне пришлось временно оставить работу в ISP и заниматься проектом было некогда. Тогда к нему подключились Upbirb и dnk2009. Исходный код появился на Google. Данным людям за помощь в проекте объявляется благодарность!

Настроить SWToolz очень просто. Требуется всего лишь задать верные community-string в файле variables.php. При желании можно создать разных пользователей и настроить им различные права.

Последняя официальная версия SWToolz - 0.99b.

DES-3028 на острие прогресса: IPv6, Телевидение, Безопасность - выберите любые два!

Эта заметка не солюшен, а лишь констатация факта специфичной проблемы DES-3028, не имеющей красивого решения. Если вы используете данную модель в своей сети и собираетесь внедрять IPv6, то знать о данной проблеме не помешает.

Выражается проблема в следующем факте: Использовать необходимый функционал коммутатора для одновременной работы IPv6, IPTV/multicast и PCF ACL невозможно из-за аппаратных ограничений модели DES-3028!

Это не значит, что от упомянутых выше технологий придется отказаться совсем, но подразумевает, что работая вместе, эти вещи будут мешать друг другу. Чтобы разобраться в этом, разберем ключевые проблемные моменты каждой из технологий в контексте предоставления услуги.

IPv6

В некоторых случаях, например для получения маршрута по умолчанию, клиент должен получать от маршрутизатора пакеты IPv6 Route Advertisements. Проблема здесь в том, что при включенном функционале filter_unregistered_groups такие пакеты коммутатором блокируются. Ниже о том, зачем все таки нужно включать фильтрацию групп.

IPTV/multicast

Управлением мультикаст-потоками на коммутаторе занимается IGMP Snooping. Он контролирует "подписки" и "отписки" клиентов к группам и отдает нужную мультикаст-группу в тот порт, за которым находится подписчик. Однако возможна ситуация, когда мультикаст на коммутаторе есть, а подписчиков в данный момент нет. В этом случае незарегистрированная группа отправится во все порты, где такие группы разрешены (forward_unregistered_groups - по умолчанию) и не будет отправлена на порты, где такие группы запрещены - filter_unregistered_groups. На практике именно включение фильтрации является хорошим решением, т.к. позволяет не пропускать абоненту мультикаст, который случайно "вырвался на свободу" из-за неполадки в каком то другом месте сети. Однако, как уже говорилось, включение этого функционала заблокирует IPv6 RA. Решением этой проблемы является включение mld_snooping - в этом случае и фильтрация будет работать, и пакеты RA будут пропущены. И все, казалось бы, хорошо, но... MLD Snooping нельзя включать одновременно с PCF ACL.

PCF ACL
Фильтрация с учетом содержимого пакета (кадра) является довольно востребованным функционалом. При помощи PCF ACL, например, можно предотвращать атаки, связанные с использованием поддельных ARP- и IP-пакетов. А ряде случаев только благодаря PCF ACL можно вписаться в лимит правил DES-3028. К сожалению, данный тип правил нельзя использовать при включенном MLD Snooping.

В результате получается тупиковая ситуация: либо настройка мультикаста блокирует ipv6, либо workaround этой проблемы блокирует возможность применения PCF ACL. Если мы попробуем использовать PCF ACL после включения MLD Snooping, то увидим сообщение "Please disable MLD snooping first!", если наоборот - "Please disable ACL UDF rule."

Единственным приемлемым решением в данной ситуации видится установка DES-3028 вторым и последним коммутатором в цепочке и выключение фильтрации незарегистрированных групп. В этом случае IPv6 RA будут проходить и не понадобится включать MLD Snooping, т.е. PCF ACL можно будет использовать. При этом сам коммутатор будет защищен от мультикаст-шторма со стороны вышестоящего коммутатора с включенной фильтрацией, а нижележащих коммутаторов за ним не будет.

Параллельный опрос коммутатора по SNMP в однопоточном режиме на Python

Если требуется получить с коммутатора сразу несколько "веток" с данными, то на ум часто приходит способ последовательного опроса. К примеру, собирая счетчики ошибок с портов, при первом опросе получаем счетчики CRC, затем спрашиваем Undersize, потом Jabber и т.п. Минус такого подхода проявится тогда, когда потребуется опросить несколько сотен или тысяч устройств. Суммарное время опроса в этом случае будет вполне ощутимым.

Однако, используя python и библиотеку netsnmp, есть возможность одновременно опрашивать сразу несколько веток. При этом как запросы, так и ответы от коммутатора, размещаются внутри одного пакета. Необходимым условием такого вопроса является одинаковая длина ветки, т.е. количество возвращаемых значений при обходе (walk) OID1 должно быть равно аналогичному числу для OID2. В противном случае опрос прекратится как будет достигнут конец самой короткой ветки OID.

Разберем ситуацию на примере ifInOctets и ifOutOctets - это 32-битные счетчики RX и TX, соответственно. Очевидно, что число значений в этих ветках одинаково (не может быть интерфейс с RX, но без TX или наоборот). Для этого воспользуемся скриптом. Python и net-snmp должны быть установлены в системе.

Мы увидим примерно следующее:
index: .1.3.6.1.2.1.2.2.1.10, vid: 1, type: COUNTER, value: 1786930814
index: .1.3.6.1.2.1.2.2.1.16, vid: 1, type: COUNTER, value: 2988734099
index: .1.3.6.1.2.1.2.2.1.10, vid: 2, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.16, vid: 2, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.10, vid: 3, type: COUNTER, value: 393989022
index: .1.3.6.1.2.1.2.2.1.16, vid: 3, type: COUNTER, value: 3964530413
index: .1.3.6.1.2.1.2.2.1.10, vid: 4, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.16, vid: 4, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.10, vid: 5, type: COUNTER, value: 2308865632
index: .1.3.6.1.2.1.2.2.1.16, vid: 5, type: COUNTER, value: 23052390
index: .1.3.6.1.2.1.2.2.1.10, vid: 6, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.16, vid: 6, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.10, vid: 7, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.16, vid: 7, type: COUNTER, value: 0
...

Если при этом мы снимали дамп, то, заглянув в него, можем увидеть такую картину:

Как видно, в одном snmp-пакете размещен один get-next-request на два параметра .1.3.6.1.2.1.2.2.1.10 и .1.3.6.1.2.1.2.2.1.16. Аналогичным образом возвращается и ответ - результаты приходят в одном пакете. Таким образом, общее число передаваемых по сети пакетов меньше, меньше и суммарное время их ожидания. Надежность передачи при этом возрастает, т.к. чем меньше пакетов, тем меньше общее число потерь. При регулярном массовом опросе сети это очень важно.

Медные магистрали и неочевидное применение протокола STP

В 2009-2010 наша сеть закончила переход на управляемое оборудование на доступе, но все еще имела большие по протяженности "гирлянды". В район приходила оптика, откуда в разные стороны тянулись цепочки коммутаторов. Иногда некоторые такие цепочки подходили достаточно близко к другим и тогда организовывались кольца. Кольца управлялись протоколом RSTP, который размыкал их в нужном месте и определял оптимальный путь к центру сети. Тем самым достигалась относительная отказоустойчивость работы - при обесточивании одного узла кольцо автоматически разрывалось, а протокол RSTP находил новое направление к центру. Сейчас считается, что "кольца на доступе - это диагноз", но тогда были другие времена. :) Несмотря на то, что кольца были организованы не везде, STP (RSTP) был настроен на всех коммутаторах, поскольку его можно было использовать с пользой совсем не по назначению.

В те времена большинство магистральных линий были медными. Делились они, в свою очередь, на два типа: "пэха" и "внешка", т.е. с использованием армейского кабеля П-296 или витой пары в жесткой оплетке (кажется, FTP), соответственно. Каждый тип линии имел свои проблемы. Кабель П-296 нуждался в дополнительной разделке, после чего он скручивался с небольшим хвостиком "внешки", который уже обжимался и затем вставлялся в коммутатор. Места "скруток" иногда окислялись, что приводило к ухудшению качества линии. Плюс ко всему, на такой линии можно было поднять только 100Мбитный линк, т.к. в кабеле П-296 всего 4 жилы. Линия же, построенная исключительно на "внешке", позволяла поднимать 1Гбитные линки, не требовала разделки и дополнительных "скруток", но ее легче было повредить и она была намного чувствительнее к статическому электричеству и прочим помехам. Вообще, по-хорошему, медные линии не должны висеть в воздухе, да и на крышах их присутствие нежелательно. Но тогда все строили как умели, а зачастую и вовсе пользовались наследием начала 2000-х.

Вернемся к STP. Точный принцип работы я не помню, но суть такова: через короткие интервалы времени с определенных администратором портов рассылаются BPDU-фреймы, содержащие информацию о топологии сети. На основе этой информации коммутаторы определяют кратчайший путь к корню - ядру сети. Если однажды появляются новые фреймы или пропадают старые - топология перестраивается. Существуют специальные указания на перестроение - Topology Change Notification. Кстати, на портах клиентов STP обычно выключают, чтобы избежать как лишних перестроений, так и несанкционированного изменения STP-дерева.

Ну и, наконец, суть. Помехи, воздействовавшие на медные линии, либо иные повреждения (окисления "скруток") могли приводить к некоторой деградации качества связи, которое не обнаруживалось явно, но мешало работе STP. Иными словами, абоненты еще не жаловались, но BPDU-фреймы уже начинали теряться, что приводило к перестроению дерева, а коммутатор оставлял в системном логе сообщение New Root Selected, где корнем становится он сам. Как правило, уже через несколько секунд топология восстанавливалась, но такие сообщения указывали на наличие проблем где то за uplink'ом данного коммутатора. Системы мониторинга, которая анализировала бы ошибки на магистральных портах, тогда еще не было (говоря по правде, ее и сейчас нет :) ), а вот система сбора логов с коммутаторов уже работала. Изучая сообщения о выборе new root можно было найти проблемный участок и предпринять меры до того, как деградация качества будет замечена абонентами.

Вот такая вот история. :) Сейчас это уже не актуально - все магистрали переведены на оптоволокно, разобраны почти все гирлянды, STP не нужен ни в каком виде, но 5 лет назад все было не так. :)

Отложенное применение конфигурации на DES-3028

Устаревшая к настоящему времени модель DES-3028 имеет интересную возможность записи конфигурационных файлов прямо во флеш-память. Это позволяет применить конфигурацию не в момент ее загрузки, а после плановой перезагрузки устройства. Реализуется это через расширение стандартной команды загрузки:

download cfg_fromTFTP 10.0.0.3 config.txt config_id 2

Файл config.txt будет скачан с TFTP-сервера 10.0.0.3 и помещен на коммутаторе в конфигурационный файл с ID 2. Загружать можно только полную (НЕ инкрементную) конфигурацию. Всего коммутатор может хранить два таких файла. Посмотреть информацию о них можно при помощи команды:

show config information

Данная команда отображает имя файла, его версию, размер, дату загрузки, используемый сервер и пользователя, выполнившего команду. Помимо этого отображается флаг (Boot up configuration), определяющий какой именно из двух файлов будет загрузочным. Поменять его можно при помощи команды:

config configuration config_id 2 boot_up

Теперь активным (загрузочным) станет второй файл, в который мы чуть раньше загрузили полный конфигурационный файл config.txt. Настройки из этого файла будут применены после перезагрузки. До нее коммутатор будет работать с текущими настройками.

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

Сброс пароля и загрузочное меню

Password Recovery Mode

Процедура сброса пароля описана в "Приложении "B"" (Appendix B - Password Recovery Procedure) документа DES-3200 Series CLI Manual.

Из соображений безопасности процедура сброса пароля может быть выполнена только при наличии физического доступа к устройству. При этом требуется подключение к консольному порту коммутатора и соответствующая программа для терминального доступа (например, Putty или Hyper Terminal).

Включите устройство. После загрузки программного обеспечения до 100% в течении двух секунд нажмите комбинацию SHIFT+6. Коммутатор перейдет в режим "Password Recovery Mode", все его порты в это время будут отключены.

В этом режиме будут доступы следующие команды:

• reset config - сброс настроек к заводским значениям.
• reboot - выход из режима восстановления и перезагрузка коммутатора.
• reset account - удаление всех ранее созданных учетных записей.
• reset password {<username>} - сброс пароля для конкретного пользователя. Если пользователь не указан, будет выполнен сброс пароля для всех пользователей.
• show account - просмотр всех ранее созданных учетных записей.

Boot Configuration Menu

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

Включите устройство. После загрузки программного обеспечения до 100% в течении двух секунд нажмите комбинацию SHIFT+3. Коммутатор перейдет в режим "Boot Configuration Menu".

В этом режиме можно:

• Выбрать тип операции с образом ПО (Create/Delete/BootUp)
• Выбрать протокол загрузки (zModem, другие варианты недоступны)
• Выбрать скорость работы с COM-портом (115200 и т.д.)

При нажатии Ctrl+S коммутатор войдет в режим ожидания передачи, на экран будет выводиться текст "Please change your baud rate to 115200 to Z modem download!!" По умолчанию порт коммутатор работает на скорости 9600. Нужно поменять ее на 115200 и начать передачу файла ПО. Сделать это можно в стандартной (для Windows) программе Hyper Terminal.

P.S. Существует команда disable password_recovery, отключающая возможность входа в "Password Recovery Mode", а при помощи специального bootprom можно запретить доступ и в режим "Boot Configuration Menu".

Обход сегментации трафика при помощи сетевого маршрута

Сегодняшняя заметка не совсем про D-Link, но информацию надо записать, чтобы не забыть. :)
В нашей сети используется схема vlan-per-switch, абонентам выделена сеть /23, где на каждого абонента приходится блок по 8 адресов (маска /29). На коммутаторе включен traffic_segmentation:

config traffic_segmentation 1-24 forward_list 25-28

Таким образом, абонентам доступна вся сеть, кроме соседей по свитчу.

Если же абоненту требуется доступ к соседу, оказывается, этого можно добиться при помощи специального маршрута, добавленного с каждой стороны. Например, абонент №1 имеет блок IP адресов 10.128.50.8/29 (1-й порт), абонент №2 - 10.128.50.112/29 (14-й порт), а общим шлюзом является адрес 10.128.50.1, то настройки будут такими:

route -p add 10.128.50.8 mask 255.255.255.248 10.128.50.1

route -p add 10.128.50.112 mask 255.255.255.248 10.128.50.1

Первая команда вводится в командной строке абонента №2, а вторая - у абонента №1. После этого клиенты смогут видеть друг друга на L3-уровне.

Инженерное меню DGS-3627G

Оказывается, на маршрутизаторе DGS-3627G имеется инженерное меню. По правде говоря, есть оно и на других моделях, но полного списка этих моделей у меня нет. Чтобы попасть в меню нужно с первой попытки залогиниться в систему со специальным паролем, уже находясь в консоли устройства.

Инструкция:

• Логинимся на маршрутизатор как обычно
• Отключаем удаленную авторизацию, если требуется (disable authen_policy), чтобы войти локально
• Вводим команду login
• Имя пользователя оставляем пустым (enter)
• Вводим пароль px10Galpha

Теперь приглашение командной строки будет заканчиваться на :128#. Появится возможность использовать новые команды. Вот некоторые расширения команды show:
address_binding_profile
arp_storm_ctrl
arpunresolved_list
asd
clibufcount
dbg_ipmc
defip_table
ethernet_oam
ethernet_oam_state_machine
fs_version
garp
global
gv_machine
ifstack
igmp_snooping_rd
imp
interface
internal
ip_tunnel_auto
ipif_ip_mtu
ipmc_l2_forward
ipv6addr
l3_table
mld_send
mld_snooping_rd
mr
mr_cnt
multi_authen
ndp_unresolvedlist
phase2_arp_unresolved
phase2_ipif_ipmtu

Полный список команд и возможностей неизвестен. За наводку спасибо dazgluk!

Некоторые факты о диагностике кабеля

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

Тесты проводились на моделях DES-3028/DES-3200-28.

1. Для портов 1-24 нет разницы, 2 или 4 пары в кабеле, т.к. в разъеме всего 4 контакта (2 пары).
2. Длина кабеля определяется только в случаях, когда коннектор никуда не вставлен, либо коннектор вставлен в работающее устройство (линк поднят/Link Up)
3. Если порт выключен программно и коммутатор определяет длину кабеля в нем, значит удаленный коннектор никуда не вставлен либо имеет место обрыв пар.
4. Если линк поднят то определится одно значение длины, если нет и удаленный коннектор не вставлен определиться длина для каждой пары.
5. Длина кабеля определяется с некоторой погрешностью - до 5 метров.
6. Диагностика кабеля длиной менее 3-х метров может приводить к результатам No Cable.
7. Диагностика никуда не подключенного кабеля существенно точнее диагностики на поднятом линке.
8. Сильное нарушение повива пар сказывается на определении длины кабеля.
9. Коммутатор DES-3028 на 10half линках показывает длину 92 метра (обнаружено недавно, детальные исследования не проводились).
10. На старых прошивках DES-3200 результаты диагностики кабеля при залинкованном порту сильно завышены.
11. Диагностика гигабитных портов приводит к кратковременному пропаданию линка независимо от используемой среды передачи (медь или оптика).
12. Для более точного результата желательно сделать несколько тестов. DES-3200-28/C1 при первом тестировании может выдать неверный результат.
13. Тестирование кабеля занимает время порядка 1-3 секунд (зависит от модели). Это надо учитывать, например, при диагностике кабеля по SNMP.
14. Диагностика по SNMP предполагает вначале инициализацию диагностики и лишь затем сбор результатов.

Защита коммутатора от DoS-атаки собственными средствами

Подопытным будет выступать коммутатор DES-3028. Все работы с ним будет осуществлять через подключение по консольному порту. Представим, что у нас в сети есть атакующих хост 10.0.0.100, трафик от которого мы должны заблокировать. Атаку на наш коммутатор (10.90.90.90) будем осуществлять при помощи примитивного python-скрипта:
#!/usr/local/bin/python
import socket

udp = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
while True:
    udp.sendto("test",("10.90.90.90",50001))

Проверим его в действии и убедимся, что загрузка CPU коммутатора очень быстро достигает 100%. Прервем работу скрипта и попробуем защитить коммутатор. Для начала используем trusted host. "Заблокируем" вообще все хосты путем указания несуществующего в нашей сети адреса:

create trusted_host 1.1.1.1

Подключиться к коммутатору теперь нельзя - соединение сразу же рвется. При этом на "ping" коммутатор отвечает (в данной модели trusted host не распространяется на ICMP ECHO). Снова атакуем коммутатор скриптом и по загрузке CPU делаем вывод, что ничего не поменялось.

Попробуем более тяжелую артиллерию и создадим блокирующее правило:

create access_profile ip source_ip_mask 255.255.255.255 profile_id 1

config access_profile profile_id 1 add access_id auto_assign ip source_ip 10.0.0.100 port all deny

Не поменялось вообще ничего - "пинги" все так же ходят, соединение устанавливается и тут же обрывается. Тогда вспомним, что для работы с трафиком, попадающим на CPU коммутатора, следует использовать CPU ACL. Создадим правила и не забудем включить сам функционал (последняя строка).

create cpu access_profile profile_id 1 ip source_ip_mask 255.255.255.255

config cpu access_profile profile_id 1 add access_id 1 ip source_ip 10.0.0.100 port all deny

enable cpu_interface_filtering

Вот теперь доступ к коммутатору пропал полностью. Причем коммутатор перестал отвечать нам на наш флуд пакетами ICMP (Destination unreachable). Снова атакуем коммутатор скриптом и видим... 100% загрузку CPU. Это говорит нам о том, что защитить коммутатор собственными средствами... проблематично. Нужно иметь это ввиду при проектировании сети - в идеале нежелательный трафик вообще не должен попадать на интерфейс коммутатора.

Доступ к описаниям портов по SNMP

С описаниями портов все не так просто, как кажется вначале. Можно получить описание через ifAlias - имя интерфейса:
1.3.6.1.2.1.31.1.1.1.18 ifAlias (s) - Текстовое интерфейса [r/w]
OID универсальный, подходит ко всем моделям. Индекс соответствует номеру порта. Отдельного описания для разных типов портов нет, поэтому в случае комбо-портов работа будет вестись с медным.

Существуют также OID и для конкретных моделей. Такой OID содержит индексы swL2PortCtrlPortIndex (номер порта) и swL2PortCtrlPortMediumType (тип среды передачи, 100 - медь, 101 - оптика). Таким образом, чтобы обратиться к порту №5, необходимо дописать ".5.100" к приведенным ниже OID.

DES-3028

.1.3.6.1.4.1.171.11.63.6.2.2.2.1.6 swL2PortCtrlDescription (s) - Текстовое описание порта [r/w]

DES-3200-28/A1/B1

.1.3.6.1.4.1.171.11.113.1.3.2.2.2.1.6 swL2PortCtrlDescription (s) - Текстовое описание порта [r/w]

Еще одна тонкость в том, что описание может вернуться как в string, так и в hex-string. Во втором случае можно воспользоваться ключом "-Oa", для преобразования значений в текст.

Получение описания первого порта для DES-3028:

snmpwalk -v2c -c public -Ona 10.90.90.90 .1.3.6.1.4.1.171.11.63.6.2.2.2.1.6.1.100

.1.3.6.1.4.1.171.11.63.6.2.2.2.1.6.1.100 = STRING: "user54321......................."

Для DES-3200-28/B1 такой ключ не потребовался. Описание сразу идет в string.

Получение описания первого порта для DES-3200-28:

snmpwalk -v2c -c public -On 10.90.90.90 .1.3.6.1.4.1.171.11.113.1.3.2.2.2.1.6.1.100

.1.3.6.1.4.1.171.11.113.1.3.2.2.2.1.6.1.100 = STRING: "user12345 H-10"

Для ревизии C1 специального OID найти не получилось. Для работы с этой серией можно использовать ifAlias.

Управление MAC Notification по SNMP

Функционал MAC Notification используется для мониторинга MAC-адресов, изучаемых коммутатором. При возникновении событий "добавление" [MAC-адреса в таблицу коммутации], "удаление" или "перемещение" будет отправлен SNMP-трап (требуется настроить snmp hosts), содержащий MAC-адрес и код операции. Функционал может быть настроен как глобально, так и для конкретного порта. Управлять этими состояними можно по SNMP.

DES-3028

.1.3.6.1.4.1.171.11.63.6.2.1.2.19.0 swL2MACNotifyState (i) - Глобальный статус MAC Notification (1 - other, 2 - disabled, 3 - enabled) [r/w]
.1.3.6.1.4.1.171.11.63.6.2.1.2.20.0 swL2MACNotifyHistorySize (i) - Максимальное число записей в сообщении [r/w]
.1.3.6.1.4.1.171.11.63.6.2.1.2.21.0 swL2MACNotifyInterval (i) - Время в секундах между оповещениями [r/w]

.1.3.6.1.4.1.171.11.63.6.2.2.2.1.8 swL2PortCtrlMACNotifyState (i) - Состояние MAC Notification для конкретного порта (1 - other, 2 - disabled, 3 - enabled) [r/w]
После swL2PortCtrlMACNotifyState идут индексы swL2PortCtrlPortIndex и swL2PortCtrlPortMediumType, то есть номер порта и его тип (100 - медь, 101 - оптика).

Для DES-3200 меняются только числовые значения, потому описание опустим, дабы не захламлять страницу. :)

DES-3200-28/A1/B1

.1.3.6.1.4.1.171.11.113.1.3.2.1.2.19.0 swL2MACNotifyState (i) [r/w]
.1.3.6.1.4.1.171.11.113.1.3.2.1.2.20.0 swL2MACNotifyHistorySize (i) [r/w]
.1.3.6.1.4.1.171.11.113.1.3.2.1.2.21.0 swL2MACNotifyInterval (i) [r/w]

.1.3.6.1.4.1.171.11.113.1.3.2.2.2.1.8 swL2PortCtrlMACNotifyState (i) [r/w]

DES-3200-28/C1

.1.3.6.1.4.1.171.11.113.5.1.2.1.2.8.0 swL2MACNotifyState (i) [r/w]
.1.3.6.1.4.1.171.11.113.5.1.2.1.2.9.0 swL2MACNotifyHistorySize (i) [r/w]
.1.3.6.1.4.1.171.11.113.5.1.2.1.2.10.0 swL2MACNotifyInterval (i) [r/w]

.1.3.6.1.4.1.171.11.113.5.1.2.3.2.1.8 swL2PortCtrlMACNotifyState (i) [r/w]
Примечание: В данном случае swL2PortCtrlPortMediumType соответствуют значения 1 для меди и 2 для оптики. В остальном отличий нет.

Параметры swL2MACNotifyHistorySize и swL2MACNotifyInterval по умолчанию выставлены в 1 и я не вижу веских причин, чтобы поменять эти значения. В большинстве случаев достаточно работать только с swL2MACNotifyState и swL2PortCtrlMACNotifyState.

Включить MAC Notification глобально для DES-3028:

snmpset -v2c -c private 10.90.90.90 .1.3.6.1.4.1.171.11.63.6.2.1.2.19.0 i 3

Включить MAC Notification на порту №1 (медь) для DES-3028:

snmpset -v2c -c private 10.90.90.90 .1.3.6.1.4.1.171.11.63.6.2.2.2.1.8.1.100 i 3

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

Получение CPU Utilization по SNMP

С коммутаторов можно получать среднее значение утилизации CPU за интервалы: 5 секунд, 1 минута и 5 минут. Для всех моделей, имеющихся у меня в наличии, OID одни и те же.

.1.3.6.1.4.1.171.12.1.1.6.1.0 agentCPUutilizationIn5sec (i) [r/o]
.1.3.6.1.4.1.171.12.1.1.6.2.0 agentCPUutilizationIn1min (i) [r/o]
.1.3.6.1.4.1.171.12.1.1.6.3.0 agentCPUutilizationIn5min (i) [r/o]

Все данные только для чтения, потому сложностей и нюансов никаких. Пример запроса утилизации за 5 минут:

snmpget -v2c -c public 10.90.90.90 .1.3.6.1.4.1.171.12.1.1.6.3.0