Обход 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, или при потере доступа к управляющей сети. Во-вторых, данная демонстрация - хороший повод задуматься над тем, как запретить подобные трюки там, где они неуместны. К сожалению, это не всегда просто сделать.

Создание Trusted Host по SNMP

Trusted Hosts - это хосты и/или сети, с которых разрешено взаимодействие с управляющим интерфейсом коммутатора. Если в списке trusted hosts нет ни одной записи, то доступ разрешен со всех адресов. При наличии записей доступ разрешен только с перечисленных сетей.

Как обычно, рассмотрим OID для моделей DES-3028, DES-3200-28/A1/B1 и DES-3200-28/C1. Других устройств у меня нет, поэтому работаем с тем, что есть. :) Как ни странно, для всех моделей OID одинаковы:

.1.3.6.1.4.1.171.12.1.2.10.1.1.2 agentTrustedHostIPAddress (a) - адрес сети
.1.3.6.1.4.1.171.12.1.2.10.1.1.3 agentTrustedHostRowStatus (i) - статус записи (нам нужен createAndGo - (4))
.1.3.6.1.4.1.171.12.1.2.10.1.1.4 agentTrustedHostIPSubnetMask (a) - маска подсети

Пример команды:

snmpset -v 2c -c private 10.0.0.10 1.3.6.1.4.1.171.12.1.2.10.1.1.2.7 a 10.0.0.0 1.3.6.1.4.1.171.12.1.2.10.1.1.3.7 i 4 1.3.6.1.4.1.171.12.1.2.10.1.1.4.7 a 255.255.255.0

В результате выполнения команды на коммутаторе 10.0.0.10 в списке trusted host появится запись для сети 10.0.0.0/24. Последняя цифра в OID указывает на номер записи. Номера не обязаны идти последовательно - в данном примере мы создаем единственную запись сразу с номером 7. Но вот перезаписать значения для уже существующей записи таким способом нельзя.

Важно: Первой следует вносить запись для той сети, откуда производится управление коммутатором. К примеру, если требуется разрешить доступ для сетей A, B и C, а команды SNMP отправляются из сети C, то данная сеть должна быть первой в списке. В противном случае управление коммутатором будет потеряно!

Важно: Механизм Trusted Host является хорошим, но недостаточным средством для защиты от несанкционированного доступа. В следующей заметке мы рассмотрим способ обхода trusted host и управление коммутатором из недоверенной сети при наличии валидного write-community.

Конфигурирование управляющего интерфейса по SNMP

По SNMP можно поменять IP-адрес, маску подсети, шлюз по умолчанию и управляющий vlan.

Для модели DES-3028 воспользуемся следующими OID:
.1.3.6.1.4.1.171.11.63.6.2.1.2.2.0 swL2DevCtrlSystemIP (a)
.1.3.6.1.4.1.171.11.63.6.2.1.2.3.0 swL2DevCtrlSubnetMask (a)
.1.3.6.1.4.1.171.11.63.6.2.1.2.4.0 swL2DevCtrlDefaultGateway (a)
.1.3.6.1.4.1.171.11.63.6.2.1.2.5.0 swL2DevCtrlManagementVlanId (i)

snmpset -v2c -c private 10.90.90.90 .1.3.6.1.4.1.171.11.63.6.2.1.2.2.0 a 10.0.0.3 .1.3.6.1.4.1.171.11.63.6.2.1.2.3.0 a 255.255.255.0 .1.3.6.1.4.1.171.11.63.6.2.1.2.4.0 a 10.0.0.1 .1.3.6.1.4.1.171.11.63.6.2.1.2.5.0 i 3

Данной командой мы меняем SystemIP на 10.0.0.3, SubnetMask на 255.255.255.0, DefaultGateway на 10.0.0.1 и ManagementVlanId на 3 (VID=3).

Для DES-3200-28/A1/B1 немного меняются числовые значения OID, а в остальном все то же самое:
.1.3.6.1.4.1.171.11.113.1.3.2.1.2.2.0 swL2DevCtrlSystemIP (a)
.1.3.6.1.4.1.171.11.113.1.3.2.1.2.3.0 swL2DevCtrlSubnetMask (a)
.1.3.6.1.4.1.171.11.113.1.3.2.1.2.4.0 swL2DevCtrlDefaultGateway (a)
.1.3.6.1.4.1.171.11.113.1.3.2.1.2.5.0 swL2DevCtrlManagementVlanId (i)

snmpset -v2c -c private 10.90.90.90 .1.3.6.1.4.1.171.11.113.1.3.2.1.2.2.0 a 10.0.0.3 .1.3.6.1.4.1.171.11.113.1.3.2.1.2.3.0 a 255.255.255.0 .1.3.6.1.4.1.171.11.113.1.3.2.1.2.4.0 a 10.0.0.1 .1.3.6.1.4.1.171.11.113.1.3.2.1.2.5.0 i 3

Для DES-3200-28/C1, как обычно, используем "черную магию":

snmpset -v2c -c private 10.90.90.90 .1.3.6.1.2.1.16.19.11.1.1.5121 a 10.0.0.3 .1.3.6.1.2.1.16.19.11.1.2.5121 a 255.255.255.0 1.3.6.1.2.1.16.19.12.0 a 10.0.0.1 .1.3.6.1.4.1.171.11.113.5.1.2.1.2.16.0 i 3

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

Работа с конфигурацией и лог-файлами коммутатора по SNMP

В одной из прошлых заметок мы научились обновлять прошивку по SNMP. Теперь поработаем с конфигурацией и лог-файлами коммутатора. Конфигурацию можно передавать в обоих направлениях, т.е. как загружать на устройство, так и выгружать с него. Лог-файл можно только выгрузить на TFTP-сервер.

Рассмотрим команды для моделей DES-3028 и DES-3200-28/A1/B1. Ревизия C1 пока не умеет загружать инкрементую конфигурацию, так что о ней в другой раз*.

Загрузка инкрементной конфигурации:

snmpset -v 2c -c private 10.90.90.90 1.3.6.1.4.1.171.12.1.2.1.1.3.3 a 10.0.0.3 1.3.6.1.4.1.171.12.1.2.1.1.5.3 s config.txt 1.3.6.1.4.1.171.12.1.2.1.1.7.3 i 3 1.3.6.1.4.1.171.12.1.2.1.1.8.3 i 3 1.3.6.1.4.1.171.12.1.2.1.1.9.3 i 1

1.3.6.1.4.1.171.12.1.2.1.1.3.3 agentBscSwFileAddr (a) 10.0.0.3 - IP-адрес TFTP-сервера
1.3.6.1.4.1.171.12.1.2.1.1.5.3 agentBscSwFile (s) config.txt - имя файла
1.3.6.1.4.1.171.12.1.2.1.1.7.3 agentBscSwFileLoadType(i) 3 - тип загрузки download
1.3.6.1.4.1.171.12.1.2.1.1.8.3 agentBscSwFileCtrl (i) 3 - тип операции start
1.3.6.1.4.1.171.12.1.2.1.1.9.3 agentBscSwFileBIncrement (i) 1 - сохранить имеющуюся конфигурацию

Параметр agentBscSwFileBIncrement, выставленный в 1, указывает коммутатору, что ему следует сохранить уже имещиеся настройки, т.е. новая конфигурация будет применена "поверх". Это позволяет загружать "неполные" конфигурационные файлы. Если в качестве значения указать 2 (не сохранять), то старые настройки будут полностью удалены. На практике в 99% случаев удобнее и правильнее использовать первый вариант, т.е. инкрементную (1) загрузку.

Если поменять agentBscSwFileLoadType на 2 (upload), то конфигурация будет выгружена на сервер. Параметр agentBscSwFileBIncrement при этом можно опустить.

Выгрузка конфигурации на TFTP-сервер:

snmpset -v 2c -c private 10.90.90.90 1.3.6.1.4.1.171.12.1.2.1.1.3.3 a 10.0.0.3 1.3.6.1.4.1.171.12.1.2.1.1.5.3 s config.txt 1.3.6.1.4.1.171.12.1.2.1.1.7.3 i 2 1.3.6.1.4.1.171.12.1.2.1.1.8.3 i 3

Выгрузка лог-файлов на TFTP-сервер:

snmpset -v 2c -c private 10.90.90.90 1.3.6.1.4.1.171.12.1.2.1.1.3.2 a 10.0.0.3 1.3.6.1.4.1.171.12.1.2.1.1.5.2 s log.txt 1.3.6.1.4.1.171.12.1.2.1.1.7.2 i 2 1.3.6.1.4.1.171.12.1.2.1.1.8.2 i 3

Как видно, OID для прошивки, логов и конфигурации отличаются только последней цифрой. Например, если agentBscSwFileAddr имеет цифровой адрес 1.3.6.1.4.1.171.12.1.2.1.1.3, то обращение к:
agentBscSwFileAddr.1 или к 1.3.6.1.4.1.171.12.1.2.1.1.3.1 - используется для работы с программным обеспечением (только загрузка)
agentBscSwFileAddr.2 или к 1.3.6.1.4.1.171.12.1.2.1.1.3.2 - используется для работы с файлом журнала (только выгрузка)
agentBscSwFileAddr.3 или к 1.3.6.1.4.1.171.12.1.2.1.1.3.3 - используется для работы с конфигурацией (выгрузка и загрузка)


*Updated 2014.11.17:

Дополню заметку информацией для DES-3200-28/C1:

.1.3.6.1.4.1.171.12.1.2.18.1.1.3 agentBscFileSystemServerAddr (a) - IP-адрес TFTP-сервера
.1.3.6.1.4.1.171.12.1.2.18.1.1.5 agentBscFileSystemServerFileName (s) - имя файла
.1.3.6.1.4.1.171.12.1.2.18.1.1.8 agentBscFileSystemLoadType (i) - тип загрузки
.1.3.6.1.4.1.171.12.1.2.18.1.1.12 agentBscFileSystemCtrl (i) - тип операции

Выгрузка конфигурации на TFTP-сервер для DES-3200-28/C1:

snmpset -v 2c -c private 10.90.90.90 1.3.6.1.4.1.171.12.1.2.18.1.1.3.3 a 10.137.130.56 1.3.6.1.4.1.171.12.1.2.18.1.1.5.3 s config.txt 1.3.6.1.4.1.171.12.1.2.18.1.1.8.3 i 2 1.3.6.1.4.1.171.12.1.2.18.1.1.12.3 i 3

Выгрузка лог-файлов на TFTP-сервер для DES-3200-28/C1:

snmpset -v 2c -c private 10.90.90.90 1.3.6.1.4.1.171.12.1.2.18.1.1.3.2 a 10.137.130.56 1.3.6.1.4.1.171.12.1.2.18.1.1.5.2 s log.txt 1.3.6.1.4.1.171.12.1.2.18.1.1.8.2 i 2 1.3.6.1.4.1.171.12.1.2.18.1.1.12.2 i 3

Обновление прошивки коммутаторов по SNMP

Для моделей DES-3200-*/A1/B1 и для DES-3028:

snmpset -v2c -c private 10.90.90.90 1.3.6.1.4.1.171.12.1.2.1.1.3.1 a 10.0.0.3 1.3.6.1.4.1.171.12.1.2.1.1.4.1 i 2 1.3.6.1.4.1.171.12.1.2.1.1.5.1 s DES-3200R_1.84.B006.had 1.3.6.1.4.1.171.12.1.2.1.1.7.1 i 3 1.3.6.1.4.1.171.12.1.2.1.1.8.1 i 3 1.3.6.1.4.1.171.12.1.2.1.1.9.1 i 2 1.3.6.1.4.1.171.12.1.2.1.1.10.1 i 1

В данном запросе мы изменяем следующие параметры:
1.3.6.1.4.1.171.12.1.2.1.1.3.1 agentBscSwFileAddr a 10.0.0.3 (IP-адрес TFTP-сервера)
1.3.6.1.4.1.171.12.1.2.1.1.4.1 agentBscSwFileTransferType i 2 (тип загрузки network-load)
1.3.6.1.4.1.171.12.1.2.1.1.5.1 agentBscSwFile s DES-3200R_1.84.B006.had (имя загружаемого файла)
1.3.6.1.4.1.171.12.1.2.1.1.7.1 agentBscSwFileLoadType i 3 (тип загрузки download)
1.3.6.1.4.1.171.12.1.2.1.1.8.1 agentBscSwFileCtrl i 3 (опция/операция - start (activate firmware))
1.3.6.1.4.1.171.12.1.2.1.1.9.1 agentBscSwFileBIncrement i 2 (не добавлять к предыдущей конфигурации (ставим false (2)))
1.3.6.1.4.1.171.12.1.2.1.1.10.1 agentBscSwFileCtrlID i 1 (image id прошивки)

Прошивка будет загружена в первый image. Часть параметров, возможно, можно опустить, но так точно работает. :) Если интересно - можете выяснить на досуге, что именно здесь не является обязательным.

Для моделей DES-3200-*/C1

snmpset -v2c -c private 10.90.90.90 1.3.6.1.4.1.171.12.1.2.18.1.1.3.1 a 10.0.0.3 1.3.6.1.4.1.171.12.1.2.18.1.1.5.1 s DES3200R_4.37.B013.had 1.3.6.1.4.1.171.12.1.2.18.1.1.8.1 i 3 1.3.6.1.4.1.171.12.1.2.18.1.1.12.1 i 3

1.3.6.1.4.1.171.12.1.2.18.1.1.3.1  (agentBscFileSystemServerAddr) a 10.0.0.3 - IP TFTP-сервера
1.3.6.1.4.1.171.12.1.2.18.1.1.5.1  (agentBscFileSystemServerFileName) s - DES3200R_4.37.B013.had - Имя загружаемого файла
1.3.6.1.4.1.171.12.1.2.18.1.1.8.1  (agentBscFileSystemLoadType) i 3 - тип загрузки download
1.3.6.1.4.1.171.12.1.2.18.1.1.12.1 (agentBscFileSystemCtrl) i 3 - тип операции Start

Важно: Все параметры должны быть перечислены в одной строке. В этом случае они будут отправлены в одном пакете. Последовательное изменение тех же самых параметров, (т.е. по одному параметру за раз) может не привести к нужному эффекту.

Методы опроса Get, Walk и BulkWalk в протоколе SNMP

Используя протокол SNMP, можно получать данные разными способами. Выбор способа зависит от задачи. Самый простой путь - использование метода Get, когда запрашивается значение ключа по конкретному адресу. При методе Walk будет последовательно опрошена вся ветка, а при BulkWalk значения будут возвращаться не поштучно, а небольшими блоками.

Попробуем получить данные для конкретного OID .1.3.6.1.2.1.1.1.0 (sysDescr.0) тремя разными способами и посмотрим на отличия в работе пакета net-snmp. Запросы в примерах обозначены Q, а ответы R. Здесь мы, по большей части, рассмотрим порядок запросов и ответов, а не их содержание.

snmpget .1.3.6.1.2.1.1.1.0

Q: get-request 1.3.6.1.2.1.1.1.0
R: get-response 1.3.6.1.2.1.1.1.0

Здесь все просто. Мы запросили заранее известный адрес и получили ответ.

snmpwalk .1.3.6.1.2.1.1.1.0

Q: get-next-request 1.3.6.1.2.1.1.1.0
R: get-response 1.3.6.1.2.1.1.2.0
Q: get-request 1.3.6.1.2.1.1.1.0
R: get-response 1.3.6.1.2.1.1.1.0

Все несколько усложнилось. Метод Walk предполагает, что в качестве начального адреса указан раздел верхнего уровня, в котором требуется найти все нижележащие адреса. Поэтому он спрашивает адрес следующего OID, используя get-next-request. Однако в get-response приходит адрес уже другой ветки, что значит, что текущая исчерпана до конца. Собственно говоря, на этом работа Walk заканчивается (нас обманули, расходимся). Дальше уже идет обычный Get-запрос на конкретный адрес. Судя по всему, это инициатива самого пакета net-snmp. Не следует ожидать подобного поведения всякий раз, когда вы используете Walk тогда, когда следовало бы применить Get.

snmpbulkwalk .1.3.6.1.2.1.1.1.0

Q: getBulkRequest 1.3.6.1.2.1.1.1.0
R: get-response 1.3.6.1.2.1.1.2.0, 1.3.6.1.2.1.1.3.0, 1.3.6.1.2.1.1.4.0 ....
Q: get-request 1.3.6.1.2.1.1.1.0
R: get-response 1.3.6.1.2.1.1.1.0

В случае с BulkWalk сложилась похожая ситуация. На запрос для getBulkRequest был возвращен связанный массив данных, но самый первый OID в нем отсутствует. Затем он запрашивается отдельно тем же способом, что в первом и втором случаях.

Теперь попробуем опросить всю ветку .1.3.6.1.2.1.1 (system), используя те же методы.

snmpget .1.3.6.1.2.1.1

Q: get-request 1.3.6.1.2.1.1
R: get-response 1.3.6.1.2.1.1 (noSuchObject)

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

snmpwalk .1.3.6.1.2.1.1

Q: get-next-request 1.3.6.1.2.1.1
R: get-response 1.3.6.1.2.1.1.1.0
Q: get-next-request 1.3.6.1.2.1.1.1.0
R: get-response 1.3.6.1.2.1.1.2.0
Q: get-next-request 1.3.6.1.2.1.1.2.0
R: get-response 1.3.6.1.2.1.1.3.0
....
Q: get-next-request 1.3.6.1.2.1.1.9.1.4.71
R: get-response 1.3.6.1.2.1.2.1.0

Здесь Walk отрабатывает как задумано - при помощи get-next-request каждый раз запрашивается следующий OID, который возвращается в get-response вместе с содержимым. Рано или поздно адрес, возвращенный в get-response, выходит за пределы запрошенного. После этого опрос прекращается, а последнее полученное значение игнорируется, т.к. относится уже к другому разделу.

snmpbulkwalk .1.3.6.1.2.1.1

Q: getBulkRequest 1.3.6.1.2.1.1
R: get-response 1.3.6.1.2.1.1.1.0 1.3.6.1.2.1.1.2.0 ... 1.3.6.1.2.1.1.9.1.2.2
Q: getBulkRequest 1.3.6.1.2.1.1.9.1.2.2
R: get-response 1.3.6.1.2.1.1.9.1.2.3 1.3.6.1.2.1.1.9.1.2.4 ... 1.3.6.1.2.1.1.9.1.2.12
Q: getBulkRequest 1.3.6.1.2.1.1.9.1.2.12
R: get-response 1.3.6.1.2.1.1.9.1.2.13 1.3.6.1.2.1.1.9.1.2.14 ... 1.3.6.1.2.1.1.9.1.2.22
...
Q: getBulkRequest 1.3.6.1.2.1.1.9.1.4.70
R: get-response 1.3.6.1.2.1.1.9.1.4.71 1.3.6.1.2.1.2.1.0 ... 1.3.6.1.2.1.2.2.1.1.8

Здесь хорошо виден механизм работы BulkWalk. Выглядит так, будто бы мы спросили get-next-request, только получили не 1 результат, как в случае с Walk, а 10 в каждом get-response (в примере для каждой строчки показаны 2 первых и последний). В последнем ответе мы опять получаем данные, относящиеся к другому разделу OID. В этот раз из 10 штук в наш раздел попадает только первый OID, а остальные будут отброшены и не отображены при выводе результатов.

Теперь подведем итоги. При опросе sysDescr.0 нам требовалось получить одно конкретное значение для определенного OID. Лучшим вариантом для этого оказался метод Get, который выполнил ровно то, что задумано, за две сетевые транзакции (вопрос и ответ). Walk и BulkWalk в этом же случае свелись в итоге к все тому же Get, т.к. ни в том ни другом случае первый ответ не содержал нужной информации. При работе с пакетом net-snmp можно получить результат, используя эти методы, но это не лучший способ, т.к. он избыточен, требует больше времени и заставляет устройство проводить ненужную работу, а сеть - передавать лишние данные. Таким образом, для "прицельного" запроса по известному заранее адресу лучше всего подходит метод Get.

А вот при опросе system метод Get оказался бесполезен. Методами же Walk и BulkWalk результат был получен, но время опроса и количество транзакций сильно отличались. По адресу system в момент опроса находилось 221 значение. Для метода Walk потребовалось 444 сетевые транзакции (221*2+1 запрос +1 ответ, указывающие на окончание ветки раздела), а для BulkWalk - всего 46 ((221+9)/10*2), т.е. почти в 10 раз меньше. Поэтому метод BulkWalk, хоть и содержит большее количество избыточных данных, зато требует гораздо меньшего количества сетевых операций, что положительно сказывается на надежности и скорости работы. Если это возможно (позволяет оборудование и рабочая среда), лучше использовать BulkWalk.

Сохранение конфигурации коммутаторов по SNMP

Сегодня небольшая заметка о том как сохранять конфигурацию коммутаторов по SNMP. Потренируемся на кошках, т.е. на DES-3028, DES-3200-*/A1/B1 и DES-3200-*/C1. Ревизия C1 стоит особняком, а для остальных моделей отличий никаких нет.

Нам понадобится OID и значение, которое нужно отправить по данному адресу. Для старых ревизий используем OID 1.3.6.1.4.1.171.12.1.2.6.0, для C1 - 1.3.6.1.4.1.171.12.1.2.18.4.0.

В документации можно увидеть следующие значения ключей:
other (1) - none of the following.
cfg-id1 (2) - save configuration ID1.
cfg-id2 (3)- save configuration ID2.
log (4) - save log.
all (5) - save both (active configuration and log)

На практике нам потребуется (2) (сохранить конфигурацию) и (5) (сохранить и конфигурацию и log коммутатора). Для ревизии C1 эти значения будут, соответственно, (2) и (4).

Немаловажно еще знать и как именно реагирует конкретная модель на SNMP-запрос. Старые ревизии при получении команды сначала исполняют ее, а затем возвращают результат. При этом на такую операцию, как сохранение конфигурации, требуется время. Это время больше стандартного snmp-таймаута. Поэтому отправляющая сторона считает, что команда не дошла и принимает повторную попытку отправки. При настройках по умолчанию команда будет отправлена триджы. При этом коммутатор сохранит конфигурацию все три раза, но его процессор будет нагружен больше обычного и на коммутаторе может сработать защитный механизм Safeguard Engine. На ревизии C1 поведение отличается - коммутатор сразу пришлет ответ, а уже потом начнет сохранять конфигурацию. Поэтому риск многократного сохранения существенно ниже (учитываем, что может потеряться обратный ответ, что приведет к повтору команды).

Таким образом, нам нужно добиться отправки запроса в единственном экземпляре. Для этого будем использовать ключ -r со значением 0, где 0 - это количество дополнительных запросов. Если же мы хотим все таки получить ответ на команду для старых ревизий, то дополнительно потребуется увеличить таймаут ожидания ответа при помощи ключа -t.

Примеры команд для DES-3028, DES-3200-*/A1/B1

Сохранить все и дождаться ответа:
snmpset -v2c -c private -t 20 -r 0 10.90.90.90 1.3.6.1.4.1.171.12.1.2.6.0 i 5
 

Сохранить только конфигурацию, не дожидаясь ответа:
snmpset -v2c -c private -r 0 10.90.90.90 1.3.6.1.4.1.171.12.1.2.6.0 i 2

Примеры команд для DES-3200-*/C1:

Сохранить все:
snmpset -v2c -c private -r 0 10.90.90.90 1.3.6.1.4.1.171.12.1.2.18.4.0 i 4
 

Сохранить только конфигурацию:
snmpset -v2c -c private -r 0 10.90.90.90 1.3.6.1.4.1.171.12.1.2.18.4.0 i 2

Успешность выполнения запроса можно посмотреть в журнале коммутатора (show log).

Macsys - системная служба для сбора syslog и mac-notify сообщений с коммутаторов D-Link

Macsys - системная служба для ОС Windows, собирающая syslog и snmptrap mac-notify сообщения с коммутаторов D-Link и сохраняющая их в базу данных MySQL. Macsys был написан потому что мне, в свое время, не удалось найти другого достойного решения для данной задачи. Сейчас же я пользуюсь unix-демоном, написанным на python, а macsys не развивается уже 3 года, но, тем не менее, он все еще может найти свое применение в инфраструктуре ISP.

Программа работает с двумя MySQL-серверами. С первого она получает список коммутаторов, от которых ожидается прием данных. Обновление этого списка происходит через указанный в настройках интервал. На второй сервер отправляются результаты. Данные отправляются по мере получения, независимо от интервала опроса первого сервера. Для syslog и для mac-notify предусмотрены отдельные таблицы. Программа использует стандартные порты для syslog и snmptrap, т.е. UDP 514 и UDP 162 соответственно. Эти порты не должны быть заняты другими приложениями.

Установка службы происходит при помощи вот такой длинной команды:
macsys.exe -install -sr mysql_server_for_reading_data -ur username -pr password -dr database -qr read_query -sw mysql_server_for_storing_data -uw username -pw password -dw database -twm mactrap_table_name -tws syslog_table_name -log extended|debug|normal -time renewal_interval

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

-sr - IP-адрес MySQL-сервера "для чтения", где содержится список устройств
-ur - Имя пользователя для подключения к серверу "для чтения"
-pr - Пароль для подключения к серверу "для чтения"
-dr - Имя базы данных на сервере "для чтения"
-qr - Запрос для выбора устройств из базы данных на сервере "для чтения"
-sw - IP-адрес MySQL-сервера "для записи", где будут сохраняться принятые сообщения
-uw - Имя пользователя для подключения к серверу "для записи"
-pw - Пароль для подключения к серверу "для записи"
-dw - Имя базы данных на сервере "для записи"
-twm - Имя таблицы для mactap на сервере "для записи"
-tws - Имя таблицы для syslog на сервере "для записи"
-log - Режим журналирования (extended|debug|normal)
-time - Интервал опроса сервера "для чтения" и обновления файла журнала

Настройки для работы с MySQL сохраняются в реестре по обычному для служб системы адресу в разделе Parameters. Но вот насчет -log и -time ничего сказать не могу - уже не помню. :)

Допустим, есть сервер 10.0.0.2 с базой данных maindb, где в таблице devices хранится информация о коммутаторах. Для сохранения полученных сообщений предполагается использовать сервер 10.0.0.4 с базой данных macsys, где в таблице mactap будет храниться информация о mac notify, а в таблице syslog - syslog-сообщения. Для подключения к 10.0.0.2 используются имя и пароль user1/pass1, а для подключения к 10.0.0.4 - user2/pass2. При этом мы хотим работу сервиса в обычном (не отладочном) режиме с интервалом обновления списка устройств в 5 минут.

Для работы программе нужны ID устройств и их IP адреса. Мы можем получить их из нашей воображаемой базы следующим запросом: "select devices.id,devices.ip from maindb.devices;"

Скопируем macsys.exe в отведенную ей директорию (у меня это c:\Windows\System2\) и подставим все параметры в командную строку:

macsys.exe -install -sr 10.0.0.2 -ur user1 -pr pass2 -dr maindb -qr "select devices.id,devices.ip from maindb.devices;" -sw 10.0.0.4 -uw user2 -pw pass2 -dw macsys -twm mactrap -tws syslog -log normal -time 5

После выполнения команды служба установится в системе.

Теперь вернемся к нашим MySQL серверам. Если первая воображаемая база данных maindb существует у нас давно и успешно обновляется, то вот на втором сервере базы данных macsys еще нет. Создадим ее:
CREATE DATABASE IF NOT EXISTS `macsys` /*!40100 DEFAULT CHARACTER SET latin1 */;

Затем создадим таблицу mactrap:
CREATE TABLE `mactrap` (
    `id` INT(4) UNSIGNED NOT NULL AUTO_INCREMENT,
    `switch_id` SMALLINT(2) UNSIGNED NOT NULL DEFAULT '0',
    `ip` INT(4) UNSIGNED NOT NULL,
    `action` TINYINT(1) UNSIGNED NOT NULL,
    `mac` CHAR(12) NOT NULL,
    `port` TINYINT(1) UNSIGNED NOT NULL,
    `datetime` INT(4) UNSIGNED NOT NULL,
    PRIMARY KEY (`id`),
    INDEX `switch_id` (`switch_id`),
    INDEX `port` (`port`),
    INDEX `mac` (`mac`),
    INDEX `datetime` (`datetime`)
)
COLLATE='latin1_swedish_ci'
ENGINE=MyISAM
AUTO_INCREMENT=0;

Теперь очередь таблицы syslog:
CREATE TABLE `syslog` (
    `id` INT(4) UNSIGNED NOT NULL AUTO_INCREMENT,
    `switch_id` SMALLINT(2) UNSIGNED NOT NULL DEFAULT '0',
    `ip` INT(4) UNSIGNED NOT NULL,
    `type` TINYINT(1) UNSIGNED NOT NULL,
    `data` CHAR(160) NOT NULL,
    `datetime` INT(4) UNSIGNED NOT NULL,
    PRIMARY KEY (`id`),
    INDEX `switch_id` (`switch_id`),
    INDEX `datetime` (`datetime`)
)
COLLATE='latin1_swedish_ci'
ENGINE=MyISAM
AUTO_INCREMENT=0;

Создадим пользователя user2:
CREATE USER 'user2'@'%' IDENTIFIED BY 'pass2';
GRANT USAGE ON *.* TO 'user2'@'%';
GRANT ALL PRIVILEGES ON `macsys`.* TO 'user2'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;

Запустим службу:
C:\Windows\System32>net start macsysservice
Служба "MAC-Trap & SysLog Server" запускается.
Служба "MAC-Trap & SysLog Server" успешно запущена.

В директории C:\Windows\System32 должен появиться файл macsys.log. Записи в нем говорят о том, что все хорошо.
2014.10.17 12:51:36 Service 'MAC-Trap & SysLog Server' started...
2014.10.17 12:51:36 Variable '[read] SQL Server' is OK
2014.10.17 12:51:36 Variable '[read] SQL User' is OK
2014.10.17 12:51:36 Variable '[read] SQL Password' is OK
2014.10.17 12:51:36 Variable '[read] SQL Database' is OK
2014.10.17 12:51:36 Variable '[read] SQL Query' is OK
2014.10.17 12:51:36 Variable '[write] SQL Server' is OK
2014.10.17 12:51:36 Variable '[write] SQL User' is OK
2014.10.17 12:51:36 Variable '[write] SQL Password' is OK
2014.10.17 12:51:36 Variable '[write] SQL Database' is OK
2014.10.17 12:51:36 Variable '[write] SQL Table MAC-Trap' is OK
2014.10.17 12:51:36 Variable '[write] SQL Table SysLog' is OK
2014.10.17 12:51:36 All variables is OK!
2014.10.17 12:51:36 Connection for SQL Server '10.0.0.2' (Read) established
2014.10.17 12:51:36 SQL Read-Query OK. 2379 rows found
2014.10.17 12:51:42 Connection for SQL Server '10.0.0.4' (Write) established

Осталось настроить коммутаторы на отправку сообщений на наш сервер, где запущена служба macsys. Предположим, сервер имеет IP-адрес 10.0.0.3, а на коммутаторах используется snmp-community "public". Выполним на коммутаторах команды:
enable syslog
create syslog host 1 ipaddress 10.0.0.3 state enable

enable mac_notification
config mac_notification ports 1-24 enable
create snmp host 10.0.0.3 v2c public

Через 5 минут служба обновит список коммутаторов с сервера и сообщит в лог-файл, сколько сообщений было получено и сколько было успешно отправлено на сервер.
2014.10.17 12:56:42 MacTrap Messages: recieved 174, sended 174
2014.10.17 12:56:42 SysLog  Messages: recieved 92, sended 92
2014.10.17 12:56:42 Connection for SQL Server '10.0.0.2' (Read) established
2014.10.17 12:56:42 SQL Read-Query OK. 2379 rows found

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

Если программой будут получены сообщения с устройства, которого нет в его списке, ID устройства будет считаться равным то ли 0, то ли пустой строке. По идее, об этом факте должно быть также сообщено в лог-файл, но этого не происходит. Сейчас, спустя 3-4 года, сложно сказать почему так. :) Быть может, записи появляются  только в режимах extended и debug. Тем не менее, в остальном это рабочее решение, которое идеально подходит для начинающих системных администраторов небольших сетей. В одной из следующих заметок я расскажу об аналогичном unix-демоне, который использую в настоящее время.

md5 (macsys.exe):
f34e56a235df1c1b4f47ada54a6c5294

sha1 (macsys.exe):
fd75d00d7cbcf9acebc3ce9646d47c70784e0263

Сам файл можно взять тут:
https://drive.google.com/file/d/0B4tByM_LyCe9S3hyZ1liNDg1SlU/view?usp=sharing

Создание VLAN по SNMP

В прошлой публикации мы рассмотрели как получать информацию о VLAN по протоколу SNMP. Теперь пришло время научиться создавать VLAN'ы, используя этот протокол.

Предположим, мы хотим создать VLAN с VID=500 и именем newvlan, где 25-28 порты  настроены как tagged, а 1-24 - как untagged.

По уже известному алгоритму преобразуем двоичные последовательности используемых портов в их шестнадцатеричное представление. При этом мы помним, что нам нужна последовательности member ports и untagged ports. Из условия задачи очевидно, что в диапазон member ports будут входить все порты (1-28).

0b11111111 11111111 11111111 11110000  - 0xFFFFFFF0 (members)
0b11111111 11111111 11111111 00000000  - 0xFFFFFF00 (untagged)

Также нам понадобится задать статус записи. Используем в данном случае createAndGo (4).
Теперь укажем в нашем запросе необходимые параметры dot1qVlanStaticName (1), dot1qVlanStaticEgressPorts (2), dot1qVlanStaticUntaggedPorts (4) и dot1qVlanStaticRowStatus (5):

snmpset -v2c -c private 10.90.90.90 .1.3.6.1.2.1.17.7.1.4.3.1.1.500 s newvlan .1.3.6.1.2.1.17.7.1.4.3.1.2.500 x fffffff000000000 .1.3.6.1.2.1.17.7.1.4.3.1.4.500 x ffffff0000000000 .1.3.6.1.2.1.17.7.1.4.3.1.5.500 i 4

Error in packet.
Reason: commitFailed
Failed object: SNMPv2-SMI::mib-2.17.7.1.4.3.1.4.500

Oops! Что-то пошло не так! Поскольку нам говорят об ошибке в dot1qVlanStaticUntaggedPorts (4) то сразу заподозрим что-то неладное в настройках untagged портов. Проверим уже существующие VLAN на коммутаторе при помощи команды show vlan:
VID             : 1           VLAN Name       : default
...
Current Untagged Ports : 1-28

Оказывается порты уже настроены как untagged в другом VLAN, а наш коммутатор (DES-3028) не позволяет настраивать сразу несколько портов как untagged. Что ж, удалим лишние порты, оставив только 1-й порт, через который подключен коммутатор. Для этого выполним config vlan default delete 2-28. Теперь требуется пересчитать hex-значение для member и untagged ports:

0b01111111 11111111 11111111 11110000  - 0x7FFFFFF0 (members)
0b01111111 11111111 11111111 00000000  - 0x7FFFFF00 (untagged)

snmpset -v2c -c private 10.90.90.90 .1.3.6.1.2.1.17.7.1.4.3.1.1.500 s newvlan .1.3.6.1.2.1.17.7.1.4.3.1.2.500 x 7ffffff000000000 .1.3.6.1.2.1.17.7.1.4.3.1.4.500 x 7fffff0000000000 .1.3.6.1.2.1.17.7.1.4.3.1.5.500 i 4

SNMPv2-SMI::mib-2.17.7.1.4.3.1.1.500 = STRING: "newvlan"
SNMPv2-SMI::mib-2.17.7.1.4.3.1.2.500 = Hex-STRING: 7F FF FF F0 00 00 00 00
SNMPv2-SMI::mib-2.17.7.1.4.3.1.4.500 = Hex-STRING: 7F FF FF 00 00 00 00 00
SNMPv2-SMI::mib-2.17.7.1.4.3.1.5.500 = INTEGER: 4

Посмотрим на коммутаторе что получилось:
VID             : 500         VLAN Name       : newvlan
VLAN Type       : Static      Advertisement   : Disabled
Member Ports    : 2-28
Static Ports    : 2-28
Current Tagged Ports   : 25-28
Current Untagged Ports : 2-24
Static Tagged Ports    : 25-28
Static Untagged Ports  : 2-24
Forbidden Ports        :

Вывод: В ходе выполнения задачи мы обнаружили, что ее нельзя выполнить дословно, т.к. порт 1 уже используется для другого VLAN. Поэтому мы переделали запрос так, чтобы исключить порт №1 из запроса и создали VLAN, который не включает в себя этот порт. Результат достигнут.

Note: Обратите внимание, что все параметры необходимо указывать в одном запросе. Последовательное выполнение четырех команд snmpset не приведет к такому же результату. Это особенность реализации функционала.

Чтение информации о VLAN по SNMP

Информацию о VLAN'ах коммутатора можно почерпнуть из раздела Dot1qVlanStaticEntry, который находится по адресу 1.3.6.1.2.1.17.7.1.4.3.1 .

Выполним команду (должен быть установлен пакет net-snmp):

snmpwalk -v2c -c public -On 10.90.90.90 .1.3.6.1.2.1.17.7.1.4.3.1

.1.3.6.1.2.1.17.7.1.4.3.1.1.1 = STRING: "default"
.1.3.6.1.2.1.17.7.1.4.3.1.1.3 = STRING: "3"
.1.3.6.1.2.1.17.7.1.4.3.1.1.3130 = STRING: "my_vlan"
.1.3.6.1.2.1.17.7.1.4.3.1.2.1 = Hex-STRING: 00 00 00 00 00 00 00 00
.1.3.6.1.2.1.17.7.1.4.3.1.2.3 = Hex-STRING: 00 00 00 F0 00 00 00 00
.1.3.6.1.2.1.17.7.1.4.3.1.2.3130 = Hex-STRING: FF FF FF E0 00 00 00 00
.1.3.6.1.2.1.17.7.1.4.3.1.3.1 = Hex-STRING: 00 00 00 00 00 00 00 00
.1.3.6.1.2.1.17.7.1.4.3.1.3.3 = Hex-STRING: 00 00 00 00 00 00 00 00
.1.3.6.1.2.1.17.7.1.4.3.1.3.3130 = Hex-STRING: 00 00 00 00 00 00 00 00
.1.3.6.1.2.1.17.7.1.4.3.1.4.1 = Hex-STRING: 00 00 00 00 00 00 00 00
.1.3.6.1.2.1.17.7.1.4.3.1.4.3 = Hex-STRING: 00 00 00 00 00 00 00 00
.1.3.6.1.2.1.17.7.1.4.3.1.4.3130 = Hex-STRING: FF FF FF 60 00 00 00 00
.1.3.6.1.2.1.17.7.1.4.3.1.5.1 = INTEGER: 1
.1.3.6.1.2.1.17.7.1.4.3.1.5.3 = INTEGER: 1
.1.3.6.1.2.1.17.7.1.4.3.1.5.3130 = INTEGER: 1


Внутри раздела Dot1qVlanStaticEntry есть следующие ключи (в примере выделены жирным шрифтом):
dot1qVlanStaticName (1) - Имя VLAN
dot1qVlanStaticEgressPorts (2) - Порты, входящие в VLAN (member ports)
dot1qVlanForbiddenEgressPorts (3) - Порты, исключенные из VLAN (forbidden ports)
dot1qVlanStaticUntaggedPorts (4) - Порты, настроенные как untagged
dot1qVlanStaticRowStatus (5) - Статус записи

Следом идет идентификатор VLAN (VID) (в примере выделен курсивом).

Рассмотрим отдельно VLAN с VID=3130:
.1.3.6.1.2.1.17.7.1.4.3.1.1.3130 = STRING: "my_vlan"
.1.3.6.1.2.1.17.7.1.4.3.1.2.3130 = Hex-STRING: FF FF FF E0 00 00 00 00
.1.3.6.1.2.1.17.7.1.4.3.1.3.3130 = Hex-STRING: 00 00 00 00 00 00 00 00
.1.3.6.1.2.1.17.7.1.4.3.1.4.3130 = Hex-STRING: FF FF FF 60 00 00 00 00
.1.3.6.1.2.1.17.7.1.4.3.1.5.3130 = INTEGER: 1

В этом примере ключи имеют следующие значения:
VLAN name: my_vlan
Member ports: FF FF FF E0 00 00 00 00
Forbidden ports: 00 00 00 00 00 00 00 00
Untagged ports: FF FF FF 60 00 00 00 00
Status: Active (1)

Осталось разобраться как интерпретировать значения вроде FF FF FF E0 00 00 00 00. На самом деле тут все просто - это побитовое перечисление портов, представленное в шестнадцатеричном виде. Последние 4 байта не используются, поэтому нас интересуют только первые 4.
0xFFFFFFE0 это 0b11111111111111111111111111100000 (member ports)
0xFFFFFF60 это 0b11111111111111111111111101100000 (untagged ports)

Удобнее разбить длинную запись 4 группы по 8 бит:
11111111 11111111 11111111 11100000 (member ports)
11111111 11111111 11111111 01100000 (untagged ports) 

Если порт N входит в member ports, то на его месте в такой последовательности стоит 1, иначе - 0. Нумерация в такой записи идет слева направо. Таким образом, в данном случае для VID=3130 member ports будут 1-27, а untagged ports - 1-24,26-27. Порт 25 входит в members, но не входит в диапазон untagged ports. Следовательно 25-й порт настроен как tagged для VID=3130.

Полезные OID для получения информации о состоянии портов по SNMP

Трафик на интерфейсах

Счетчик входящих данных (RX) 64 bit
.1.3.6.1.2.1.31.1.1.1.6 - ifHCInOctets

Счетчик исходящих данных (TX) 64bit
.1.3.6.1.2.1.31.1.1.1.10 - ifHCOutOctets

Счетчик входящих данных (RX) 32 bit
.1.3.6.1.2.1.2.2.1.10 - ifInOctets

Счетчик исходящих данных (TX) 32bit
.1.3.6.1.2.1.2.2.1.16 - ifOutOctets

 

Ошибки

Счетчики ошибок для входящих данных (RX)

CRC
.1.3.6.1.2.1.16.1.1.1.8 - etherStatsCRCAlignErrors
(Является суммой dot3StatsAlignmentErrors и dot3StatsFCSErrors, .1.3.6.1.2.1.10.7.2.1.2 и .1.3.6.1.2.1.10.7.2.1.3, соответственно)

Undersize
.1.3.6.1.2.1.16.1.1.1.9 - etherStatsUndersizePkts

Oversize
.1.3.6.1.2.1.16.1.1.1.10 - etherStatsOversizePkts

Fragment
.1.3.6.1.2.1.16.1.1.1.11 - etherStatsFragments

Jabber
.1.3.6.1.2.1.16.1.1.1.12 - etherStatsJabbers

 

Счетчики ошибок для исходящих данных (TX)

Collision
.1.3.6.1.2.1.16.1.1.1.13 - etherStatsCollisions

Single Collision
.1.3.6.1.2.1.10.7.2.1.4 - dot3StatsSingleCollisionFrames

Excessive Defferal
.1.3.6.1.2.1.10.7.2.1.7 - dot3StatsDeferredTransmissions

Late Collision
.1.3.6.1.2.1.10.7.2.1.8 - dot3StatsLateCollisions

Excessive Collision
.1.3.6.1.2.1.10.7.2.1.9 - dot3StatsExcessiveCollisions

 

Диагностика кабеля

Состояние линка
.1.3.6.1.4.1.171.12.58.1.1.1.3 - swEtherCableDiagLinkStatus

Статус 1-й пары
.1.3.6.1.4.1.171.12.58.1.1.1.4 - swEtherCableDiagPair1Status

Статус 2-й пары
.1.3.6.1.4.1.171.12.58.1.1.1.5 - swEtherCableDiagPair2Status

Статус 3-й пары
.1.3.6.1.4.1.171.12.58.1.1.1.6 - swEtherCableDiagPair3Status

Статус 4-й пары
.1.3.6.1.4.1.171.12.58.1.1.1.7 - swEtherCableDiagPair4Status

Длина 1-й пары
.1.3.6.1.4.1.171.12.58.1.1.1.8 - swEtherCableDiagPair1Length

Длина 2-й пары
.1.3.6.1.4.1.171.12.58.1.1.1.9 - swEtherCableDiagPair2Length

Длина 3-й пары
.1.3.6.1.4.1.171.12.58.1.1.1.10 - swEtherCableDiagPair3Length

Длина 4-й пары
.1.3.6.1.4.1.171.12.58.1.1.1.11 - swEtherCableDiagPair4Length

Примечание: Для DES-3028 и DES-3200-28/A1/B1 следует работать с парами под номерами №1 и №2, а в случае с DES-3200-28/C1 - с №2 и №3.

Инициализация диагностики
.1.3.6.1.4.1.171.12.58.1.1.1.12 - swEtherCableDiagAction
Пример: snmpset .1.3.6.1.4.1.171.12.58.1.1.1.12.24 i 1 -  Запустить диагностику на 24-м порту
После запуска теста надо подождать 1-2 секунды, после чего можно забирать результат

 

Состояние портов

DES-3200-28 A1/B1:
Административный статус порта (включен или выключен)
.1.3.6.1.4.1.171.11.113.1.3.2.2.2.1.3 - swL2PortCtrlAdminState

Фактическое состояние линка (есть ли линк или нет)
.1.3.6.1.4.1.171.11.113.1.3.2.2.1.1.4 - swL2PortInformationLinkStatus

Административно заданная скорость на порту
.1.3.6.1.4.1.171.11.113.1.3.2.2.2.1.4 - swL2PortCtrlNwayState

Фактическая скорость на порту
.1.3.6.1.4.1.171.11.113.1.3.2.2.1.1.5 - swL2PortInfoNwayStatus

DES-3200-18 A1/B1:
Административный статус порта (включен или выключен)
.1.3.6.1.4.1.171.11.113.1.2.2.2.2.1.3 - swL2PortCtrlAdminState

Фактическое состояние линка (есть ли линк или нет)
.1.3.6.1.4.1.171.11.113.1.2.2.2.1.1.4 - swL2PortInformationLinkStatus

Административно заданная скорость на порту
.1.3.6.1.4.1.171.11.113.1.2.2.2.2.1.4 - swL2PortCtrlNwayState

Фактическая скорость на порту
.1.3.6.1.4.1.171.11.113.1.2.2.2.1.1.5 - swL2PortInfoNwayStatus

DES-3200-28 C1:
Административный статус порта (включен или выключен)
.1.3.6.1.4.1.171.11.113.5.1.2.3.2.1.4 - swL2PortCtrlAdminState

Фактическое состояние линка (есть ли линк или нет)
.1.3.6.1.4.1.171.11.113.5.1.2.3.1.1.5 - swL2PortInformationLinkStatus

Административно заданная скорость на порту
.1.3.6.1.4.1.171.11.113.5.1.2.3.2.1.5 - swL2PortCtrlNwayState

Фактическая скорость на порту
.1.3.6.1.4.1.171.11.113.5.1.2.3.1.1.6 - swL2PortInfoNwayStatus

DES-3200-18 C1:
Административный статус порта (включен или выключен)
.1.3.6.1.4.1.171.11.113.3.1.2.3.2.1.4 - swL2PortCtrlAdminState

Фактическое состояние линка (есть ли линк или нет)
.1.3.6.1.4.1.171.11.113.3.1.2.3.1.1.5 - swL2PortInformationLinkStatus

Административно заданная скорость на порту
.1.3.6.1.4.1.171.11.113.3.1.2.3.2.1.5 - swL2PortCtrlNwayState

Фактическая скорость на порту
.1.3.6.1.4.1.171.11.113.3.1.2.3.1.1.6 - swL2PortInfoNwayStatus

DES-3028:
Административный статус порта (включен или выключен)
.1.3.6.1.4.1.171.11.63.6.2.2.2.1.3 - swL2PortCtrlAdminState

Фактическое состояние линка (есть ли линк или нет)
.1.3.6.1.4.1.171.11.63.6.2.2.1.1.4 - swL2PortInformationLinkStatus

Административно заданная скорость на порту
.1.3.6.1.4.1.171.11.63.6.2.2.2.1.4 - swL2PortCtrlNwayState

Фактическая скорость на порту
.1.3.6.1.4.1.171.11.63.6.2.2.1.1.5 - swL2PortInfoNwayStatus