Управление службами 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 одинаковые. Не исключено, что пример будет работать и на других моделях.