С Новым 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

Управление службами Web и Telnet по SNMP

По SNMP можно включать/выключать Web/Telnet-серверы.

DES-3028

.1.3.6.1.4.1.171.11.63.6.2.1.2.27.1.0 swL2DevCtrlWebState (i) - Состояние Web-службы (1 - other, 2 - disabled, 3 - enabled) [r/w]
.1.3.6.1.4.1.171.11.63.6.2.1.2.28.1.0 swL2DevCtrlTelnetState (i) - Состояние Telnet-службы (1 - other, 2 - disabled, 3 - enabled) [r/w]

DES-3200-28/A1/B1

.1.3.6.1.4.1.171.11.113.1.3.2.1.2.30.1.0 swL2DevCtrlWebState (i) - Состояние Web-службы (1 - other, 2 - disabled, 3 - enabled) [r/w]
У этой модели мне не удалось найти OID для Telnet-службы. Быть может этот функционал не реализован.

DES-3200-28/C1

.1.3.6.1.4.1.171.11.113.5.1.2.1.2.14.1.0 swL2DevCtrlTelnetState (i) - Состояние Telnet-службы (1 - other, 2 - disabled, 3 - enabled) [r/w]
.1.3.6.1.4.1.171.11.113.5.1.2.1.2.14.2.0 swL2DevCtrlTelnetTcpPort (i) - Telnet-порт [r/w]

.1.3.6.1.4.1.171.11.113.5.1.2.1.2.17.1.0 swL2DevCtrlWebState (i) - Состояние Web-службы (1 - enabled, 2 - disabled) [r/w]
.1.3.6.1.4.1.171.11.113.5.1.2.1.2.17.2.0 swL2DevCtrlWebTcpPort (i) - Web-порт [r/w]
У ревизии C1 появилась возможность менять порты для служб Web и Telnet. Обратите внимание, если во всех остальных случаях включение сервиса - это (3), то в случае ревизии C1 и Web, это уже (1). Чем руководствовались разработчики - загадка. При изменении порта перезапуск соответствующей службы не требуется.

Выключить Web-сервер на DES-3200-28/C1:

snmpset -v2c -c private 10.90.90.90 .1.3.6.1.4.1.171.11.113.5.1.2.1.2.17.1.0 i 1

Некоторые нюансы DES-3028 при построении ACL

Модель DES-3028 давно снята с производства, но все еще широко эксплуатируется в ISP. И есть у этой модели некоторые особенности, которые нужно учитывать при создании ACL.

Кадры внутри коммутатора могут иметь метку 802.1Q (tag), а могут и не иметь.

Пример нетегированного кадра:

70 71 bc 0c  39 b7 68 b5  99 8f df 07  08 06 00 01
08 00 06 04  00 02 68 b5  99 8f df 07  0a 89 82 30
70 71 bc 0c  39 b7 0a 89  82 38 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00            

Пример этого же кадра, но с тегом:

70 71 bc 0c  39 b7 68 b5  99 8f df 07  xx xx xx xx
08 06 00 01  08 00 06 04  00 02 68 b5  99 8f df 07
0a 89 82 30  70 71 bc 0c  39 b7 0a 89  82 38 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00

Во втором случае видно, что все данные, кроме DST MAC и SRC MAC сместились на 4 байта - именно столько занимает описание тега в стандарте 802.1Q. Это надо помнить, когда мы создаем ACL правила на основе содержимого кадра (Packet Content Filtering).

Пример правила блокировки всех ARP для untagged-фреймов:

create access_profile packet_content_mask offset_0-15 0x0 0x0 0x0 0xffff0000 profile_id 6
config access_profile profile_id 6 add access_id auto_assign packet_content offset 12 0x08060000 port 11 deny

Все ARP в тегированных кадрах будут пропущены, т.к. EtherType в таких кадрах будет находиться на 4 байта правее.


Пример правила блокировки всех ARP для tagged-фреймов:

create access_profile packet_content_mask offset_16-31 0xffff0000 0x0 0x0 0x0 profile_id 6
config access_profile profile_id 6 add access_id auto_assign packet_content offset 16 0x08060000 port 11 deny

Все ARP в нетегированных кадрах будут пропущены, т.к. EtherType в таких кадрах будет находиться на 4 байта левее.

Эта особенность может создать серьезные неудобства при проектировании и тестировании правил, но ее же можно попытаться использовать с пользой. Обычно в ISP весь трафик, кроме идущего непосредственно к абоненту, передается тегированным. Таким образом, по отсутствию тега можно отличать абонентский трафик от всего остального. Это позволяет "навешивать" правила, блокирующие нежелательный абонентский трафик, на все порты, не опасаясь при этом за остальной трафик, и одновременно экономить ресурсы ACL (см. следующий пункт).

Важно: При тестировании имейте ввиду, что ОС Windows по умолчанию снимает метку 802.1Q со всех кадров. Настроить иное поведение очень непросто. Это означает, что все кадры, которые вы видите в Wireshark, гарантированно будут нетегированными.

На один порт всегда расходуется одно правило. Соответственно, на диапазон портов расходуется столько правил, сколько в него попало портов. Исключение - весь диапазон. В этом случае расходуется всего одно правило.

Например, если мы создаем 5 правил и назначаем их на абонентские порты (1-24), то мы израсходуем 24*5=120 правил. В запасе у нас останется 256-120=136 правил. Но если мы назначим эти же правила на все порты (1-28), то израсходуем всего лишь 5*1=5 правил и еще 251 останется в запасе. Чтобы иметь возможность экономить правила таким образом, может потребоваться переработать большинство правил на PCF, т.к. в этом случае появится возможность отличать абонентский трафик от прочего по наличию тега.

Информация от D-Link по поводу ACL и DSCP

Коммутатор может менять поле DSCP только на основании значения этого же поля DSCP. В критериях ACL не может быть никаких других параметров, в том числе и UDP портов.
Если трафик приходит без метки DSCP, то на DES-3028 можно только смеппить пакет в нужную очередь, а менять поле DSCP придется уже на вышестоящем коммутаторе (естественно при наличии такой возможности).

Этот момент мной не тестировался, но информация совпадает с темой данной заметки, потому размещаю ее здесь.

Управление функционалом LoopBack Detect по SNMP

Про LBD мы уже немного поговорили вот здесь. Теперь научимся управлять этим функционалом по SNMP. Вся эта информация есть в MIB, здесь мы просто собираем ее в одном месте для удобства.

DES-3028

.1.3.6.1.4.1.171.11.63.6.2.21.1.1.0 swL2LoopDetectAdminState (i) - Глобальный статус LBD (1 - enabled, 2 - disabled) [r/w]
.1.3.6.1.4.1.171.11.63.6.2.21.1.2.0 swL2LoopDetectInterval (i) - Интервал обнаружения в секундах [r/w]
.1.3.6.1.4.1.171.11.63.6.2.21.1.3.0 swL2LoopDetectRecoverTime (i) - Время восстановления в секундах (0 - не восстанавливать порт) [r/w]
.1.3.6.1.4.1.171.11.63.6.2.21.1.5.0 swL2LoopDetectTrapMode (i) - Режим отправки trap (1 - none, 2 - loop_detected, 3 - loop_cleared, 4 - both) [r/w]

.1.3.6.1.4.1.171.11.63.6.2.21.2.1.1.2 swL2LoopDetectPortState (i) - Статус LBD на порту (1 - enabled, 2 - disabled) [r/w]
.1.3.6.1.4.1.171.11.63.6.2.21.2.1.1.4 swL2LoopDetectPortLoopStatus (i) - Статус порта (1 - normal, 2- loop, 3 - error) [r/o]

В серии DES-3200 появляются параметры swL2LoopDetectMode и swL2LoopDetectPortLoopVLAN. В остальном все идентично, поэтому описание дублировать не буду. Числовые значения OID во всех этих моделях отличаются.

DES-3200-28/A1/B1

.1.3.6.1.4.1.171.11.113.1.3.2.21.1.1.0 swL2LoopDetectAdminState
.1.3.6.1.4.1.171.11.113.1.3.2.21.1.2.0 swL2LoopDetectInterval
.1.3.6.1.4.1.171.11.113.1.3.2.21.1.3.0 swL2LoopDetectRecoverTime
.1.3.6.1.4.1.171.11.113.1.3.2.21.1.4.0 swL2LoopDetectMode (i) - Режим обнаружения (1 - vlan-based, 2 - port-based) [r/w]
.1.3.6.1.4.1.171.11.113.1.3.2.21.1.5.0 swL2LoopDetectTrapMode

.1.3.6.1.4.1.171.11.113.1.3.2.21.2.1.1.2 swL2LoopDetectPortState
.1.3.6.1.4.1.171.11.113.1.3.2.21.2.1.1.3 swL2LoopDetectPortLoopVLAN (s) - Список vlan, где обнаружена петля [r/o]
.1.3.6.1.4.1.171.11.113.1.3.2.21.2.1.1.4 swL2LoopDetectPortLoopStatus

DES-3200-28/C1

.1.3.6.1.4.1.171.11.113.5.1.2.18.1.1.0 swL2LoopDetectAdminState (i) [r/w]
.1.3.6.1.4.1.171.11.113.5.1.2.18.1.2.0 swL2LoopDetectInterval (i) [r/w]
.1.3.6.1.4.1.171.11.113.5.1.2.18.1.3.0 swL2LoopDetectRecoverTime (i) [r/w]
.1.3.6.1.4.1.171.11.113.5.1.2.18.1.4.0 swL2LoopDetectMode (i) - Режим обнаружения (1 - vlan-based, 2 - port-based) [r/w]
.1.3.6.1.4.1.171.11.113.5.1.2.18.1.5.0 swL2LoopDetectTrapMode (i)[r/w]

.1.3.6.1.4.1.171.11.113.5.1.2.18.2.1.1.2 swL2LoopDetectPortState (i) [r/w]
.1.3.6.1.4.1.171.11.113.5.1.2.18.2.1.1.3 swL2LoopDetectPortLoopVLAN (s) - Список vlan, где обнаружена петля [r/o]
.1.3.6.1.4.1.171.11.113.5.1.2.18.2.1.1.4 swL2LoopDetectPortLoopStatus (i) [r/o]

Включить LBD глобально и на 20-м порту:

snmpset -v2c -c private 10.90.90.90 .1.3.6.1.4.1.171.11.63.6.2.21.1.1.0 i 1 .1.3.6.1.4.1.171.11.63.6.2.21.2.1.1.2.20 i 1

Получение состояний светодиодов передней панели DES-3200-28/C1 по SNMP

Модель DES-3200-28/C1 позволяет получить по SNMP состояние светодиодов передней панели коммутатора. Это довольно полезная возможность, удобная еще и тем, что много параметров возвращается в одном запросе.

Вот этот OID, доступный только для чтения:
.1.3.6.1.4.1.171.11.113.5.1.2.1.1.4.0 swDevInfoFrontPanelLedStatus

Возвращаемое значение содержит набор описаний LED-индикаторов (светодиодов).

Первые два байта описывают состояние PoE:
01 02 = PoE Mode
02 01 = Normal Mode
00 00 = Non-PoE Device

Третий байт указывает на состояние индикатора питания:
0x01 : Power Off
0x02 : Power On

Четвертый байт соответствует индикатору консоли:
0x01 = system start up
0x02 = a user is login through console
0x03 = no user is login through console

Пятый байт указывает на состояние RPS (Redundancy Power Supply).
0x01 = Internal Power working
0x02 = External Power working

Шестой байт соответствует индикатору состояния FAN:
0x01 = Fan LED Off
0x02 = Fan LED blinking

Следующие байты описывают состояние логических портов. Каждые два байта соответствуют одному порту.
Первый байт указывает на состояние светодиода, сигнализирующего об активности линка (Link/Activity LED), а второй соответствует индикатору скорости (Speed LED).

Расшифровка значений для Link/Activity LED:
Левая часть левого байта используется для определения состояния "мигающий светодиод/горящий светодиод"
8 = The LED blinks.

Правая часть левого байта используется для описания состояния линка:
1 = link fail.
2 = link pass.

Расшифровка значения для Speed LED:

Нормальный режим:
Левая часть правого байта указывает на тип подключения:
0 = copper link up (if link fail will show 0)
1 = fibber link up

Правая часть правого байта указывает на скорость подключения:
01 = 10Mbps.
02 = 100Mbps.
03 = 1000Mbps.
04 = 10000Mbps.

Режим POE:
01 = no PD connected.
02 = no deliver power to PD.
03 = deliver power to PD.

Разберем ситуацию на примере. Отправим команду:

snmpget -v2c -c public 10.90.90.90 .1.3.6.1.4.1.171.11.113.5.1.2.1.1.4.0

Коммутатор вернул значение:
00 00 02 01 01 02 82 02 01 01 01 01 01 01 01 01
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 82 13 01 01 01 01 01 01

00 00 - Указывает на то, что мы использует коммутатор без поддержки PoE.
02 - Питание включено (даже не спрашивайте, в каких случаях коммутатор вернет 01). :)
01 - Система стартовала.
01 - Работа от внутреннего источника питания. Наверное, имеется ввиду встроенный БП.
02 - Светодиод вентилятора моргает. (Может он просто расстроен от того, что на данной модели нет вентиляторов).
82 02 - Светодиод порта №1 мигает (8), линк поднят (2). Линк медный (0), скорость 100 Мбит/с (2).
01 01 - Светодиод портов №2-24,26-28 не мигает (0), линк не поднят (1). Тип подключения не определен (0, в сочетании с link fail), скорость 0 Мбит/с (1 указывает на 10 Мбит/сек, но раз линк не поднят, то будем считать ее равной 0).
...
...
82 13 - Светодиод порта №25 мигает (8), линк поднят (2). Линк оптический (1), скорость 1 Гбит/с (3).

Планирование перезагрузки DES-3200-28/C1 по SNMP

В модели DES-3200-28/C1, начиная с прошивки 4.37.B006, а также в модели DES-3200-28/A1/B1, начиная с прошивки 1.84.B012, появилась возможность перезагрузки по расписанию. Можно запланировать перезагрузку через некоторое время, а можно указать конкретное время и дату. Через консоль это реализуется при помощи команды "config reboot schedule in|at". Здесь мы попробуем разобраться, как управлять данным функционалом по SNMP. Судя по всему, в MIB'ах информация еще не обновлена, поэтому разбираться пришлось методом научного тыка. Удалось найти OID для DES-3200-28/C1, поэтому именно с этой моделью сегодня и будем работать.

Итак, вот этот OID:

1.3.6.1.4.1.171.12.1.2.32

Имени у него пока нет. Но нам хватит и этого. :) Если перезагрузка не запланирована, то по этому адресу мы ничего не найдем. Если запланирована, получим нечто вроде такого:
.1.3.6.1.4.1.171.12.1.2.32.1.2.1 = INTEGER: 60
.1.3.6.1.4.1.171.12.1.2.32.1.3.1 = Hex-STRING: 13 1B
.1.3.6.1.4.1.171.12.1.2.32.1.4.1 = Hex-STRING: 15 0B 07 DE
.1.3.6.1.4.1.171.12.1.2.32.1.5.1 = INTEGER: 2
.1.3.6.1.4.1.171.12.1.2.32.1.10.1 = INTEGER: 1

Расшифровка значений:
60 - Количество минут, которые должны пройти до перезагрузки. Это число уменьшается со временем, но не сразу и полностью полагаться на него нельзя.
13 1B - Время, на которое запланирована перезагрузка. В данном случае 19:27.
15 0B 07 DE - Дата перезагрузки. В примере 21.11.2014.
2 - Флаг, указывающий, выполнять (1) ли сохранение конфигурации перед перезагрузкой или нет (2). Можно изменить на "ДА" (1) один раз. Вернуть на "НЕТ" (2) уже не получится.
1 - Неизвестный параметр.

Запланировать перезагрузку через 60 минут:

snmpset -v2c -c private 10.90.90.90 1.3.6.1.4.1.171.12.1.2.32.1.2.1 i 60

Примечание: Максимальное значение 1 месяц, т.е. 24*60*30=43200 минут.

Сохранить конфигурацию перед перезагрузкой:

snmpset -v2c -c private 10.90.90.90 1.3.6.1.4.1.171.12.1.2.32.1.5.1 i 1

Обратите внимание, что когда мы планируем перезагрузку через некоторый интервал, этот интервал будет обновлен на первоначальное значение каждый раз, когда мы что-то правим в настройках. Например, в 10:00 мы запланировали перезагрузку через 60 минут, а спустя 20 минут спохватились и сказали коммутатору, что ему надо будет еще сохранить конфигурацию. В этом случае время снова сдвинется на 60 минут и перезагрузка будет запланирована уже на 11:20. Если же мы планируем перезагрузку на точное время, то оно в дальнейшем не меняется.

Запланировать перезагрузку на 05:55 22.11.2014 с сохранением конфигурации:

snmpset -v2c -c private 10.90.90.90 1.3.6.1.4.1.171.12.1.2.32.1.3.1 x 0537 1.3.6.1.4.1.171.12.1.2.32.1.4.1 x 160b07de 1.3.6.1.4.1.171.12.1.2.32.1.5.1 i 1

Проверяем наши ключи:
.1.3.6.1.4.1.171.12.1.2.32.1.2.1 = INTEGER: 669
.1.3.6.1.4.1.171.12.1.2.32.1.3.1 = Hex-STRING: 05 37
.1.3.6.1.4.1.171.12.1.2.32.1.4.1 = Hex-STRING: 16 0B 07 DE
.1.3.6.1.4.1.171.12.1.2.32.1.5.1 = INTEGER: 1
.1.3.6.1.4.1.171.12.1.2.32.1.10.1 = INTEGER: 1

Смотрим чт получилось на самом коммутаторе:
 Reboot Schedule Settings
 ---------------------------
 Reboot schedule at 22 Nov 2014 05:55:00 (in 669 minutes)
 Save before reboot: Yes

Как видно, все сходится.

Перезагрузка коммутаторов по SNMP

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

Модель DES-3200-28/C1, как обычно, стоит особняком, поэтому сначала о DES-3028 и DES-3200-28/A1/B1.

Перезагрузить их можно при помощи общего OID:
.1.3.6.1.4.1.171.12.1.2.3.0 agentSystemReset (i) - warm-start (3)

А можно при помощи специфического для DES-3028:
.1.3.6.1.4.1.171.11.63.6.2.1.2.1.0 swL2DevCtrlSystemReboot (i)

И для DES-3200-28/A1/B1:
.1.3.6.1.4.1.171.11.113.1.3.2.1.2.1.0 swL2DevCtrlSystemReboot (i)

Записываемые значения: other(1), reboot(2), save-config-and-reboot(3), reboot-and-load-factory-default-config(4)
Думаю, по названию все понятно.

Пример перезагрузки DES-3028 и DES-3200-28/A1/B1 по общему OID:

snmpset -v2c -c private 10.90.90.90 .1.3.6.1.4.1.171.12.1.2.3.0 i 3

Пример перезагрузки модели DES-3028 с сохранением конфигурации (save-config-and-reboot - 3):

snmpset -v2c -c private 10.90.90.90 .1.3.6.1.4.1.171.11.63.6.2.1.2.1.0 i 3

Пример перезагрузки модели DES-3200-28 с сохранением конфигурации (save-config-and-reboot - 3):

snmpset -v2c -c private 10.90.90.90 .1.3.6.1.4.1.171.11.113.1.3.2.1.2.1.0 i 3

 

Теперь перейдем к DES-3200-28/C1. Несмотря на то, что agentSystemReset присутствует в MIB, воспользоваться им нельзя. Видимо это задел на будущее либо же обычный недосмотр. Спасает то, что в дополнение там появляется agentReboot:

.1.3.6.1.4.1.171.12.1.2.19.0 agentReboot (i) - start (2)

То есть в старый моделях ребут назывался резетом, а в новой называется ребутом. Но и резет при этом есть, только там уже будет не ребут, а, собственно, резет, т.е. сброс. Можно запутаться, поэтому перед тем, как что-то делать, не мешает лишний раз все проверить.

Пример перезагрузки DES-3200-28/C1:

snmpset -v2c -c private 10.90.90.90 1.3.6.1.4.1.171.12.1.2.19.0 i 2

Дополнения и работа над ошибками #1

Сегодня без заметок, но обновлены и подправлены записи про полезные OID и работу с логами и конфигурацией. Добавлены пояснения и примеры для DES-3200-28/C1.

Функционал LoopBack Detection и раскрытие информации

Функционал LoopBack Detection (LBD) предназначен для выявления петель в широковещательных сегментах. Суть метода довольно проста: коммутатор отправляет специальный кадр в сеть и если этот кадр вернулся назад, считается, что за данным портом петля.

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

Формат кадра

Адрес назначения: CF-00-00-00-00-00
Адрес источника: MAC коммутатора + № порта. Например, если MAC коммутатора 34:08:04:36:AB:D0, тогда кадры с 1-го порта имеют SRC MAC 34:08:04:36:AB:D1, с 7-го - 34:08:04:36:AB:D7 и т.д.
Тип Ethernet: 9000
Затем идут 4 служебных байта с номером функции и 42 байта с данными. При этом блок с данными может содержать только номер порта.

Поймать такой кадр можно при помощи Wireshark, выставив в фильтре захвата значение ether proto 0x9000.

Пример кадра

CF 00 00 00 00 00 34 08 04 36 AB D7 90 00 00 00
00 01 00 07 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00

В данном кадре после ethernet type (90 00) идут 4 байта Configuration Test Protocol (00 00 00 01), а затем следует блок данных, начинающийся с 00 07. Эти два байта содержат номер порта. Таким образом, этот кадр был отправлен с 7-го порта, а MAC коммутатора - 34:08:04:36:AB:D0 (D7 - 7 = D0). Когда коммутатор получает такой кадр он берет SRC MAC и вычитает из него первые два байта из блока данных. Если то, что получилось, равно его собственному MAC, то это указывает на наличие петли за портом, откуда такой кадр был получен.

Из всего сказанного можно сделать следующие выводы:

• Можно спровоцировать блокировку собственного порта, отправив пойманный (или специально подготовленный) кадр назад в сеть.
• Нельзя обмануть коммутатор и заставить его заблокировать чужой порт при помощи поддельного кадра, т.к. номер порта из кадра используется лишь как вычитаемое.
• Номер порта не имеет значения. К примеру, можно указать в кадре порт 65244 (FE DC). Коммутатору не важно, что у него нет порта с таким номером. Главное, чтобы SRC MAC был увеличен на это же число. Кстати, номер порта может быть равен даже 00 00.
• Кадр сам по себе раскрывает некоторую информацию, а именно MAC устройства и номер порта. Используя приведенные ниже списки можно попытаться определить по MAC-адресу коммутатора его модель и ревизию.

DES-3028

00:19:5B:ED, 00:19:5B:EE, 00:1C:F0:11, 00:1C:F0:9E, 00:1C:F0:D0, 00:1C:F0:D1, 00:1E:58:46, 00:1E:58:A0, 00:1E:58:A6, 00:1E:58:A8, 00:21:91:52, 00:21:91:53, 00:21:91:91, 00:21:91:92, 00:21:91:96, 00:21:91:97, 00:22:B0:04, 00:22:B0:50, 00:22:B0:51, 00:22:B0:52

DES-3200-28/A1

00:26:5A:8A, 00:26:5A:8B, 00:26:5A:8D, 00:26:5A:8E, 00:26:5A:8F, 00:26:5A:90, 00:26:5A:91, 14:D6:4D:6E, 14:D6:4D:6F, 1C:AF:F7:90, 1C:BD:B9:46, 1C:BD:B9:47, 1C:BD:B9:48, 1C:BD:B9:F1, 34:08:04:36, 34:08:04:37, 34:08:04:38, 34:08:04:39, 34:08:04:3A, 34:08:04:3B, 34:08:04:3C, 34:08:04:5F, 5C:D9:98:0D, 5C:D9:98:12, 5C:D9:98:13, 5C:D9:98:41, 5C:D9:98:FA, 5C:D9:98:FB, F0:7D:68:3B

DES-3200-18/A1

1C:BD:B9:9A, 1C:BD:B9:9B

DES-3200-28/B1

14:D6:4D:BD, 14:D6:4D:BE, 14:D6:4D:BF, 14:D6:4D:C0, 14:D6:4D:C1, 84:C9:B2:9A, 84:C9:B2:AF, 84:C9:B2:B0, 84:C9:B2:B3, 84:C9:B2:B4, 84:C9:B2:B5, FC:75:16:F4, FC:75:16:F9, FC:75:16:FD, FC:75:16:FE

DES-3200-18/B1

28:10:7B:F9, 28:10:7B:FA

DES-3200-28/C1

70:62:B8:3B, 78:54:2E:41, 90:94:E4:24, 90:94:E4:25, 90:94:E4:26, 90:94:E4:B9, 90:94:E4:BA, 90:94:E4:BB, 90:94:E4:BC, 90:94:E4:BD, AC:F1:DF:B2, AC:F1:DF:BA, B0:C5:54:88, B0:C5:54:89, B0:C5:54:8A, B0:C5:54:97, B0:C5:54:98, B0:C5:54:9A, B0:C5:54:9C, C4:A8:1D:03, C4:A8:1D:04, C4:A8:1D:05, C4:A8:1D:10, C4:A8:1D:11, C4:A8:1D:12, C8:BE:19:F8, C8:BE:19:F9, C8:BE:19:FA, CC:B2:55:79, CC:B2:55:7A, CC:B2:55:7B, CC:B2:55:7C, CC:B2:55:88, CC:B2:55:89, CC:B2:55:8A, D8:FE:E3:89, D8:FE:E3:8A, D8:FE:E3:8B, D8:FE:E3:8C, D8:FE:E3:8F, D8:FE:E3:98, D8:FE:E3:EB, D8:FE:E3:EC, EC:22:80:24, EC:22:80:34, EC:22:80:35

DES-3200-18/C1

9C:D6:43:FC, 9C:D6:43:FD, C8:BE:19:92, C8:BE:19:95, C8:BE:19:FB, C8:BE:19:FC

Примечание: В списках указаны первые 4 байта MAC-адреса, если считать слева направо.

p.s. Если коммутатор используется как relay-агент, то при помощи снифера можно поймать пакеты DHCP, где указан IP-адрес коммутатора. Таким образом, со стороны клиента может быть получена следующая информация о коммутаторе: 1) IP-адрес; 2) MAC-адрес; 3) Модель и ревизия; 4) Номер порта для данного подключения. Это позволяет в дальнейшем провести атаку на само устройство. Поэтому важно позаботиться о том, чтобы сеть управления коммутаторами не была доступа со стороны клиента.

Настройка SysLog по SNMP

Для DES-3028 и DES-3200-28/A1/B1/C1 OID одинаковы. По SNMP можно настроить: а) Общее состояние SysLog; б) Параметры конкретных записей; в) Сохранение логов на коммутаторе. Также можно очистить текущий лог.

Общее состояние SysLog

.1.3.6.1.4.1.171.12.12.1.0 swSysLogCtrlState (i) - Глобальное состояние SysLog (2 - выключено, 3 - включено)

snmpset -v2c -c private 10.90.90.90 1.3.6.1.4.1.171.12.12.1.0 i 3

Данной командой SysLog будет включен глобально.

Параметры конкретных записей

.1.3.6.1.4.1.171.12.12.2.1.2 swSysLogServerIPAddress (a) - IP-адрес SysLog-сервера
.1.3.6.1.4.1.171.12.12.2.1.3 swSysLogServerFacility (i) - Категория сообщения (0 - Local0, 7 - Local7 и т.д.)
.1.3.6.1.4.1.171.12.12.2.1.4 swSysLogServerSeverity (i) - "Важность" сообщения (1 - all, 2 - warning, 7 - error, 9 -  debug и т.д.)
.1.3.6.1.4.1.171.12.12.2.1.5 swSysLogServerUDPPort (i) - UDP порт SysLog-сервера
.1.3.6.1.4.1.171.12.12.2.1.6 swSysLogServerState (i) - Состояние записи (2 - выключено, 3 - включено)
.1.3.6.1.4.1.171.12.12.2.1.7 swSysLogServerRowStatus (i) - Статус записи (4 - создать, 1 - перезаписать, 6 - удалить)

В запросе необязательно указывать все параметры. Если что-то будет пропущено, соответствующий параметр примет значение по умолчанию. В самом простом случае достаточно указание IPAddress, State и RowStatus.
В конце OID добавляется индекс, который может принимать значения от 1 до 4, т.к. всего можно создать до 4-х записей.

Пример команды:
snmpset -v2c -c private 10.90.90.90 1.3.6.1.4.1.171.12.12.2.1.2.4 a 10.0.0.3 1.3.6.1.4.1.171.12.12.2.1.6.4 i 3 1.3.6.1.4.1.171.12.12.2.1.7.4 i 4

На DES-3028 при этом появится запись с индексом 4:
Host Id  Host IP Address  Severity        Facility  UDP port  Status
-------  ---------------  --------------  --------  --------  --------
4        10.0.0.3         All             Local0    514       Enabled

Сохранение логов на коммутаторе

.1.3.6.1.4.1.171.12.12.3.1.0 swLogSaveMethod (i) -  Способ сохранения логов на коммутаторе (1 - через интервал времени, 2 - по требованию, 3 - при возникновении события)
.1.3.6.1.4.1.171.12.12.3.2.0 swLogSaveTimeInterval (i) - Интервал времени в минутах

По умолчанию DES-3028 настроен на сохранение логов по требованию, а интервал указан в 65535 минут. Переопределим эти значения:
snmpset -v2c -c private 10.90.90.90 .1.3.6.1.4.1.171.12.12.3.1.0 i 1 .1.3.6.1.4.1.171.12.12.3.2.0 i 240

Теперь коммутатор будет сохранять свой лог в памяти каждые 4 часа (240/60).
Примечание: В момент применения команды лог-файл будет сохранен. Из-за этого ответ может прийти с задержкой.

Удалить лог-файл с коммутатора

.1.3.6.1.4.1.171.12.12.4.1.0 swSysLogCtrlClearLog (i) - Управление очисткой лог-файла (2 - старт процедуры)

snmpset -v2c -c private 10.90.90.90 .1.3.6.1.4.1.171.12.12.4.1.0 i 2

Лог файл будет удален. Никаких записей об этом на коммутаторе не останется.
Примечание: Операция также потребует времени. Ответ может прийти с некоторой задержкой.

Последствия конфликта MAC-адресов

Продолжаем тему прошлой заметки. Здесь пойдет речь об очевидных и не очень последствиях появления "конфликтующих" MAC-адресов.

Самой очевидной проблемой, конечно же, будет отсутствие всех "пересекающихся" MAC-адресов в таблице коммутации. При получении кадра, адресованного такому MAC'у, коммутатор не сможет определить порт назначения (Destination Lookup Failure, DLF) и кадр будет отправлен во все порты, являющиеся участниками данного VLAN, кроме того, откуда данный кадр был получен. Тем самым коммутатор (свитч) превращается в концентратор (хаб), т.е. не справляется со своей основной задачей - коммутацией трафика. Чем больше пересекающихся MAC-адресов в сети, тем больше лишнего трафика по ней перемещается. Часть кадров при этом может теряться и конечный потребитель не получает небходимой "скорости".

Как решение здесь напрашивается сегментация сети на VLAN'ы меньшего размера, вплоть до vlan-per-user. Широковещательный домен при этом уменьшится, количество передаваемого по сети мусора тоже. В случае vlan-per-user проблема, казалось бы, устраняется полностью. Но не все так просто.

Есть еще два VLAN, которые не могут быть уменьшены слишком уж сильно. Это управляющий (management) и мультикаст (mvr) вланы. Поскольку конфликты запросто происходят между разными влан, то пересечение с абонентским MAC может вызвать "замусоривание" управляющего влана либо ухудшение работы IPTV*.

Следующая проблема - сам механизм обнаружения таких конфликтов (enable flood_fdb), где производятся вычисления, аналогичные тем, что выполняются в ASIC. То есть это не извлечение проблемного адреса из недр памяти, а вычисление, проводящееся параллельно работе чипа. Только в этом случае расходуются уже ресурсы CPU. Отсюда следует, что большой поток трафика может привести к ненужной нагрузке на CPU. На практике, к сожалению, так и получается. В модели DES-3028 CPU уходит в 100% загрузку и устройство становится недоступным. При том, если коммутатор выступает в роли релей-агента, то абоненты перестают получать адреса от DHCP. На DES-3200-28/A1/B1 ситуация несколько отличается - коммутатор с некоторой вероятностью не может ответить на ARP-запрос. Когда время жизни arp на маршрутизаторе истекает, коммутатор на некоторое время становится недоступен. Результатом будет "моргающая" карта сети.

Комментарий D-Link:
Ситуация вызвана тем, что flood_fdb (как и обсуждалось ранее) - софтовый функционал. Исправить это нет никакой возможности, рекомендация - использовать flood_fdb только для анализа проблемных ситуаций и не держать его включенным повсеместно на сети.
Загрузка cpu будет напрямую зависеть от количества, типа трафика и пр, но каких-то конкретных значений pps сказать не представляется возможным.

Таким образом, использовать flood_fdb можно только в не нагруженных сетях без мультикаста.

Еще одна проблема, предположительно связанная с "конфликтом hash" - глюки дополнительного функционала коммутаторов. Например, IP-MAC-Port Binding в режиме DHCP Snooping блокирует кадры от абонента несмотря на наличие валидной связки в своей таблице.

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

Вывод: Конфликтующие MAC-адреса, помимо явной проблемы с коммутацией трафика рано или поздно приведут к труднодиагностируемым побочным проблемам. Единственный правильный выход из ситуации - физически сегментировать сеть, тем самым уменьшая общее количество MAC-адресов на проблемных устройствах**.

Меры, помогающие снизить ущерб:
1. Уменьшение размеров абонентских VLAN.
2. Уменьшение размера управляющего VLAN.
3. Отказ от использования MVR (мультикаст вещается в абонентском VLAN или не вещается вовсе).
4. Отключение изучения MAC-адресов на коммутаторах, включение сегментации трафика, когда абонент может передать кадр только в аплинк, использование auto_fdb (если позволяют свободные ресурсы коммутатора).
5. Установка проблемных коммутаторов** в конец цепочки.
6. Отказ от использования функционала IMP

Эти меры помогут выиграть время для грамотного перепланирования сети.

* Мультикаст вещается на специальные адреса для групповой рассылки, которые обрабатываются коммутатором несколько иначе, чем обычные адреса, но пересечения MAC все равно могут приводить к описанной проблеме.
** Все вышенаписанное применимо, прежде всего, к DES-3028 и DES-1228/ME/A1. На DES-3200 проблема практически никогда не достигает серьезных масштабов

Проблема "конфликт hash" на сетевых коммутаторах

Под конфликтом hash подразумевается такая ситуация, когда из-за организации внутренней логики коммутатора некоторые MAC-адреса считаются равными друг другу. В результате такой "ошибки" в таблицу коммутации попадает только первый MAC, а кадры, предназначенные конфликтующим MAC, разлетаются по всей сети. В постсовестких интернетах расцветом этой проблемы можно считать 2009-2010 года. Вот интересная ветка на НАГ'е, где можно почитать первые возгласы возмущения. Но некоторым сетевым администраторам проблема уже была известна. На том же НАГ'е есть статья, которая содержит технические подробности и настоятельно рекомендуется к прочтению*. А в этой заметке я попытаюсь понятно изложить природу явления для тех, кто еще не сталкивался с описанной ситуацией.

Причина "конфликта"

В памяти коммутатора MAC-адреса не хранятся как таковые. Хранятся лишь некоторые значения hash-функции, вычисленные на основе MAC и VLAN. Выглядит это примерно так: val1=hashfunc(mac1+vlan1). Другая запись для другой пары mac2 и vlan2 будет, соответственно, val2=hashfunc(mac2+vlan2). При этом для хранения подобных значений память выделяется в условиях строжайшей экономии. Грубо говоря, уникальность каждой записи реализована с некоторыми допущениями. Поэтому вероятность того, что val2 будет равно val1 существенно отличается от нуля. Если такое происходит, то mac2 считается равным mac1. Из всех таких MAC-адресов коммутатором будет изучен только первый, т.к. отличий между ними коммутатор не видит.

Проблемные модели

Из модельного ряда D-Link модели в порядке убывания вероятности конфликта можно расположить так:

• DES-3028 (чипсет BCM 5347), DES-1228/ME/A1 (чипсет BCM 5347, аппаратный аналог 3028)
• DES-3200-28/A1/B1  (чипсет BCM 53262), DES-1228/ME/B1 (чипсет BCM 53262), DES-1210-28/ME/B2 (чипсет BCM 53262)
• DES-3528, DES-3526
• DES-3200-28/C1

Возможно, стоило бы поместить серию 35xx и 3200-28/C1 в один ряд, но точных цифр у меня нет, потому пусть будет так.

Комментарии D-Link

1. Чипсеты всех современных моделей подвержены данным проблемам. Поскольку основных производителей всего два: Broadcom и Marvell, то у многих вендоров наблюдается данная проблема в той или иной степени на разных сериях коммутаторов. Старые чипсеты имели 2-х уровневый хеш, а не одноуровневый как новые, поэтому на них практически отсутствует
данная проблема, что и показывают тесты. Производители чипсетов увеличили скорость работы FDB таблицы, но как побочный эффект получили проблему с хешами. Также многое зависит от того, как реализованная память под FDB таблицу и сколько бит отпущено под одну хеш запись.
2. Наличие проблемы хэширования вовсе не говорит о том, что данная модель плохая! Каждая модель коммутатора имеет свою маркетинговую нишу и предполагает ее правильно использование. Например модели DES-3028 и DES- 3200 в большей степени рассчитаны на использование с операторской моделью QinQ. Модель DES-3528 расчитана на корпоративный сегмент, где цена оборудования имеет меньше значения нежели требуемый функционал. Модель DES-1210-xx рассчитана на использование с операторской моделью без QinQ.
3. Как видно из проведенных тестов у модели DES-3028 самая низкая устойчивость хэш функции к длинным последовательностям (самый большой процент коллизий), поэтому при использовании данной конкретной модели мы рекомендовали их (длинные последовательности) избегать. В других моделях данная проблема отсутствует.

В принципе, все так. На DES-3028 проблема выражена остро, на DES-3200-28/A1/B1 - постольку-поскольку, а на остальных моделях (из перечисленных) может быть замечена только при явно ошибочном проектировании сети.

Обнаружение проблемы

а) Устройство в сети доступно, MAC-адрес корректный (см. бит для групповой рассылки), но на порту не обнаруживается.
б) При помощи специального функционала enable flood_fdb. Коммутатор начнет следить за MAC-адресами и вести в памяти копию (т.е. этот функционал - исключительно мониторинг) конфликтов. Посмотреть табличку конфликтов можно командой show flood_fdb
Value  VLAN ID MAC  Address        Time Stamp
------ ------- ------------------- ----------
3865   24      00-22-B0-04-6A-17 * 9978796
3865   1511    00-1A-79-11-85-E4   9978796

Одинаковое value указывает на конфликт. Звездочка говорит о том, что MAC-адрес присутствует в таблице коммутации. Таким образом, "проблемным" в данном примере является MAC 00-1A-79-11-85-E4.

В DES-3200-28/C1 такого механизма нет, т.к. считается, что данная модель не подвержена проблеме "конфликт hash".

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

* В статье упоминается серия коммутаторов DES-32xx. Судя по дате написания статьи, речь идет о моделях типа DES-3226, а не о серии DES-3200.

Установка штатного TFTP-сервера под Windows

Когда требуется загрузить конфигурацию, обновить программное обеспечение устройства или выгрузить файл журнала, то не обойтись без TFTP-сервера. Под ОС Windows часто рекомендуют использовать Tftpd32. Это неплохой вариант. Однако не всем известно, что в TFTP-сервер входит в комплект поставки Windows серверных версий. Поскольку такой сервис установить несложно, работает он как служба и "есть не просит", то я предпочитаю именно его. Ниже о том, где его найти и как установить.

В папке I386 внутри дистрибутива Windows 2003 Server возьмем два файла EXPAND.EXE и TFTPD.EX_. Запустим командную строку от имени администратора и выполним следующие команды:

EXPAND.EXE TFTPD.EX_ tftpd.exe

copy tftpd.exe %windir%\system32\

sc create tftpd start= auto binPath= %windir%\system32\tftpd.exe

reg add hklm\system\currentcontrolset\services\tftpd\Parameters /v Directory /t REG_SZ /d c:\tftproot

md c:\tftproot

net start tftpd

После этого мы должны увидеть сообщение об успешном запуске:
Служба "tftpd" запускается.
Служба "tftpd" успешно запущена.

При необходимости можно заменить каталог c:\tftproot на любой другой. Файлы EXPAND.EXE и TFTPD.EX_ больше не нужны, их можно удалить.

Все, можно пользоваться сервисом. Главное - проверить, что UDP 69 не блокируется нашим firewall. Поскольку сервис работает как служба, им можно пользоваться не выполняя вход в систему.

Утечка SNMP-community в DES-3028

Модель DES-3028 имеет неприятную особенность. SNMP-community доступны для просмотра всем пользователям.

DES-3028:3#show snmp community
Command: show snmp community

SNMP Community Table

Community Name                    View Name                         Access Right
-------------------------------  -------------------------------  ------------
private                          CommunityView                    read_write
public                           CommunityView                    read_only

Total Entries: 2

DES-3028:3#

Уровень привилегий 3 соответствует правам user. Знание community с правами read_write фактически повышает привилегии до уровня admin. D-Link не относит эту проблему к критичным, поэтому фикса не предвидится, поскольку серия 3028 уже EOL. Имейте ввиду этот момент при разграничении прав доступа.

Нестандартная маска в правилах PCF

Механизм Packet Content Filtering, как это и следует из названия, позволяет фильтровать пакеты по их содержимому. Конкретное действие определяется правилом. Группа однотипных правил помещается в профиль. В профиле указывается смещение, в котором следует искать нужную последовательность байт, и маска, под которую они должны попадать. Пример создания правил для DES-3200-28/A1/B1 можно посмотреть вот тут.

Здесь я хочу рассказать не о самих правилах, а об используемой маске. В большинстве примеров используется маска, где выбираются или отбрасываются байты целиком. Например, по ссылке выше можно увидеть маску 0x00ff. Это означает, что первый байт в этой паре может быть любым, а второй должен быть задан явно. Однако ничего не мешает задавать маску побитово. Это может быть использовано для управления последовательностью данных. Например, так можно отфильтровать несколько идущих подряд IP-адресов.

Посмотрим на этот пример:

create access_profile packet_content_mask c_tag 0xFFF0 offset1 l2 0 0x0 profile_id 1

config access_profile profile_id 1 add access_id auto_assign packet_content c_tag 0x0000 port all permit

config access_profile profile_id 1 add access_id auto_assign packet_content c_tag 0x0010 port all permit

Оффсет здесь задается для совместимости с "недокументированными особенностями", но больше нас интересует C-tag, который является тегом 802.1Q и состоит из Priority, Canonical Format Indicator (CFI) и VLAN Identifier (VID). Для удобства будем считать приоритет не заданным (0b000), а CFI - каноническим (0b0), тем более, в большинстве случаев так и получается. Оставшиеся 12 бит (16 минус 3 Priority и минус 1 CFI) относятся к VID.

Обратим внимание на маску:

1111 1111  1111 0000 - FFF0

Такая маска означает, что 12 бит (считая слева) должны быть заданы явно, а вот последние 4 могут быть любыми. Эти 4 бита позволяют нам нарезать вланы блоками по 16 штук (2^4).

Сравним маску FFF0 с первым правилом, где c_tag указан как 0x0000:

1111 1111  1111 0000 - FFF0
0000 0000  0000 0000 - 0000
....
0000 0000  0000 1111 - 000F

Под такую маску для первого правила попадут все VID от 0 до F, т.е. от 0 до 15

Аналогично проведем сравнение со вторым правилом, где c_tag указан как 0x0010:

1111 1111  1111 0000 - FFF0
0000 0000  0001 0000 - 0010
....
0000 0000  0001 1111 - 001F

Под такую маску для попадут все VID от 10 до 1F, т.е. от 15 до 31

Таким образом мы описали 32 влан двумя правилами.

Аналогичный пример можно привести и для работы с ARP:

#permit ARP with correct 4th octet (between port*8 and port*8+7)
create access_profile packet_content_mask offset1 l2 0 0xFFFF offset2 l3 16 0xF8 profile_id 5
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x08 port 1 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x10 port 2 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x20 port 4 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x28 port 5 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x30 port 6 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x38 port 7 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x40 port 8 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x48 port 9 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x50 port 10 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x58 port 11 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x60 port 12 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x68 port 13 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x70 port 14 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x78 port 15 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x80 port 16 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x88 port 17 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x90 port 18 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x98 port 19 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0xa0 port 20 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0xa8 port 21 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0xb0 port 22 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0xb8 port 23 permit
config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0xc0 port 24 permit

#deny arp
create access_profile packet_content_mask offset1 l2 0 0xFFFF profile_id 6
config access_profile profile_id 6 add access_id auto_assign packet_content offset1 0x0806 port 1-24 deny

В профиле №5 разрешаются ARP-ответы из диапазона Port*8 <= 4th_oct <= Port*8+7. Всего 8 возможных вариантов IP для каждого порта. 24 правилами описаны 192 адреса. Это становится возможным из-за маски 0xF8 (0x11111000), которой явно определяются только первые 5 бит адреса. Затем, в профиле №6 мы блокируем все остальные ARP-ответы.

Как видно, использование "побитовой" маски в сочетании с планированием адресного пространства с учетом "компьютерной" логики позволяет экономить правила, которые не бесконечны.

Настройка времени на коммутаторах по SNMP

Не так давно время снова перевели. Если кто не успел перенастроить оборудование то эта заметка может пригодиться.

Для точной настройки времени существует достаточно много ключей, но нам понадбятся только эти:

.1.3.6.1.4.1.171.12.10.10.4 swSystemTimeZone (i) - Time Zone

.1.3.6.1.4.1.171.12.10.11.1.0 swSNTPState (i) - SNTP enabled (3)
.1.3.6.1.4.1.171.12.10.11.3.0 swSNTPServer1IPAddr (a) - SNTP Primary Server
.1.3.6.1.4.1.171.12.10.11.4.0 swSNTPServer2IPAddr (a) - SNTP Secondary Server
.1.3.6.1.4.1.171.12.10.11.5.0 swSNTPPollInterval (i) - SNTP Poll Interval

.1.3.6.1.4.1.171.12.10.12.1.0 swSummerTimeStatus (i) - Daylight Saving Time disabled (0)

Примеры команд для настройки московского времени и отключения перехода на летнее время:

snmpset -v2c -c private 10.90.90.90 .1.3.6.1.4.1.171.12.10.10.4.0 i 180

snmpset -v2c -c private 10.90.90.90 .1.3.6.1.4.1.171.12.10.11.1.0 i 3
snmpset -v2c -c private 10.90.90.90 .1.3.6.1.4.1.171.12.10.11.3.0 a 10.200.201.180
snmpset -v2c -c private 10.90.90.90 .1.3.6.1.4.1.171.12.10.11.4.0 a 10.200.201.34
snmpset -v2c -c private 10.90.90.90 .1.3.6.1.4.1.171.12.10.11.5.0 i 720

snmpset -v2c -c private 10.90.90.90 .1.3.6.1.4.1.171.12.10.12.1.0 i 0

Все команды можно поместить в один запрос либо отправить поштучно, как выше. На 3028 и 3200-28 всех ревизий OID одинаковые. Не исключено, что пример будет работать и на других моделях.

Обход Trusted Host при помощи SNMP и поддельного IP-адреса

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

Пакет с данными, предназначенными хосту сети, может быть передан двумя способами - напрямую (в пределах одной подсети) или через маршрутизатор (если подсети разные). При передаче напрямую выполняется только коммутация фрейма, а при передаче через маршрутизатор осуществляется еще и роутинг пакета, где происходит подмена MAC-адреса, но верхние уровни также остаются без изменения. По большому счету, роутинг пакета - это последовательная коммутация фрейма между всеми участниками цепочки. Маршрутизатор заглядывает внутрь пакета только для того, чтобы получить представление о дальнейшем пути его движения. Таким образом, независимо от способа передачи, IP-адрес отправителя никак не участвует в работе. Иными словами, этот адрес может быть любым. Это может быть использовано для обхода IP-фильтров, таких, как trusted hosts.

Сложность такого метода заключена в том, что в большинстве случаев требуется двусторонний обмен, который в такой схеме невозможен. Если мы захотим подключиться к коммутатору, используя поддельный IP-адрес, соединение не будет установлено. Посмотрим на рисунок и проследим перемещение пакетов и кадров между устройствами. Представим, что мы пытаемся подключиться по протоколу телнет к коммутатору S с компьютера PC1, используя "подставной" компьютер PC2, IP-адрес которого находится в списке доверенных хостов коммутатора S. Каждое устройство находится в своей подсети.


Пытаемся установить подключение к коммутатору S и отправляем пакет, в котором подделан IP-адрес отправителя.
MAC(R):MAC(PC1)/IP(PC2):IP(S) - фрейм со вложенным пакетом отправляется на маршрутизатор R с компьютера PC1
MAC(S):MAC(R)/IP(PC2):IP(S) - фрейм модифицируется и передается дальше к коммутатору S с маршрутизатора R

Коммутатор видит, что IP-адрес коммутатора PC2 находится в списке trusted host и сообщает PC2 о готовности принять соединение.
MAC(R):MAC(S)/IP(S):IP(PC2) - фрейм со вложенным пакетом отправляется на машрутизатор R с коммутатора S
MAC(PC2):MAC(R)/IP(S):IP(SPC2) - фрейм модифицируется и передается дальше от маршрутизатора R к компьютеру PC2

Компьютер PC2, увидев пакет с подтверждением, который он не ожидал, проигнорирует его. На этом все закончится.

В итоге:
+ Пакет успешно дошел до получателя
+ IP-фильтр коммутатора успешно пройден
- Положительный ответ коммутатора ушел на другой компьютер

Последний минус перекрывает остальные плюсы. Соединение не может быть установлено.

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

По ссылке находится пример скрипта, который позволяет добавить по SNMP некоторую сеть в список доверенных хостов коммутатора. Для этого понадобится: а) Установленный Python + Scapy; б) Валидное write-community; в) IP-адрес из списка trusted host коммутатора. Синтаксис и пример использования будут показаны при запуске программы без параметров.

Если Python и Scapy может поставить любой, то вот узнать write-community и настроенные на коммутаторе доверенные сети не так то просто. Для чего же тогда все это надо? Во-первых, для того, чтобы получить доступ к коммутатору, недоступному из-за ошибки при настройке trusted host, или при потере доступа к управляющей сети. Во-вторых, данная демонстрация - хороший повод задуматься над тем, как запретить подобные трюки там, где они неуместны. К сожалению, это не всегда просто сделать.