Ingress Checking и LLDP

После месячного перерыва появилась тема для новой заметки. На этот раз поговорим об LLDP и Ingress Checking. Если кому-то интересна предыстория, с ней можно ознакомиться здесь. Ниже я просто опишу выводы.

На моделях DES-3200-XX A1/B1 согласно информации от D-Link "начиная с прошивки 1.52.B004 Ingress Checking действует также и на BPDU пакетики, поэтому PVID магистральных портов должен быть равен VID реально существующего на них влана либо нужно отключать Ingress Checking."

На практике это означает, что для работы LLDP следует либо выключить Ingress Checking совсем, либо для каждого коммутатора подбирать настройки с учетом имеющихся на нем VLAN'ов.

Что же такое Ingress Checking*? Это "проверка попадания" кадра в набор VID, ассоцирированных с портом. Если функционал Ingress Checking включен, то при поступлении в порт коммутатора кадра производится сравнение VID кадра с набором идентификаторов VID, ассоциированных с портом (включая PVID порта). Если нет, то кадр отбрасывается. Если же функционал Ingress Checking выключен, то никакой проверки не производится.

В моем случае получалось, что VLAN на порту отсутствовал, но фрейм с его ID прилетал на коммутатор, который заносил MAC-адрес в таблицу коммутации. Немного подумав, коммутатор выкидывал этот MAC из таблицы коммутации до истечения fdb aging time. Видимо, он сам чувствовал, что здесь что-то не так! Но через несколько секунд MAC появлялся в таблице снова. В результате коммутатор генерировал большое количество MAC-notify трапов, благодаря чему, собственно, и был найден. После включения Ingress Checking безобразия прекращались, но переставал работать LLDP. Происходило так потому, что магистральные порты не настраивались как untagged, поэтому PVID там был равен 1. А после удаления с портов vlan default фреймы LLDP попадали под проверку функционалом Ingress Checking и отбрасывались.

Решение было найдено следующее: прописывать на магистральных портах PVID равный VID multicast-vlan'a. Удобство здесь в том, что данный VLAN присутствует на всех коммутаторах сети и на каждом имеет один и тот же ID. Это позволяет указывать такой PVID одинаковым для любого коммутатора, независимо от имеющихся на нем VLAN. В результате и настройка одинакова для всех коммутаторов и LLDP работает и некорректные фреймы с абонентских портов блокируются.

*Updated 2017.08.23:
Теперь приведено описание Ingress Checking для более общего случая. Раньше описывался вариант для untagged-порта.

С Новым 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. Аналогичным образом возвращается и ответ - результаты приходят в одном пакете. Таким образом, общее число передаваемых по сети пакетов меньше, меньше и суммарное время их ожидания. Надежность передачи при этом возрастает, т.к. чем меньше пакетов, тем меньше общее число потерь. При регулярном массовом опросе сети это очень важно.