DES-2108 B1 с прошивкой 5.01.B01, при тестировании управления по SNMP обнаружились следующие проблемы:
1. Read-Only Community - на самом деле не Read-Only!
Проверяю следующим образом: после сброса кнопкой ввожу в telnet команды:
Код:
config switch system_group_interval 0
enable snmp
config snmp community read_only comm_name qwerty
config snmp community read_write comm_name asdfgh
save
Далее пробую оба имени на чтение - работают:
Код:
$ snmpget -v1 -c qwerty 192.168.0.1 SNMPv2-MIB::sysName.0
SNMPv2-MIB::sysName.0 = STRING:
$ snmpget -v1 -c asdfgh 192.168.0.1 SNMPv2-MIB::sysName.0
SNMPv2-MIB::sysName.0 = STRING:
Пробую писать через read_write community - тут всё правильно:
Код:
$ snmpset -v1 -c asdfgh 192.168.0.1 SNMPv2-MIB::sysName.0 s "test1"
SNMPv2-MIB::sysName.0 = STRING: test1
$ snmpget -v1 -c qwerty 192.168.0.1 SNMPv2-MIB::sysName.0
SNMPv2-MIB::sysName.0 = STRING: test1
Затем пробую писать через read_only community - и почему-то эта запись тоже проходит успешно:
Код:
$ snmpset -v1 -c qwerty 192.168.0.1 SNMPv2-MIB::sysName.0 s "test2"
SNMPv2-MIB::sysName.0 = STRING: test2
$ snmpget -v1 -c qwerty 192.168.0.1 SNMPv2-MIB::sysName.0
SNMPv2-MIB::sysName.0 = STRING: test2
Записанное значение видно также через telnet (в show switch), а также сохраняется после выключения питания.
Получается, что read_only для SNMP - фикция; фактически оба community разрешают запись.
2. Дубли в BRIDGE-MIB::dot1dTpFdbTableСнова сбрасываю конфигурацию кнопкой, затем настраиваю через telnet:
Код:
config switch system_group_interval 0
enable snmp
create vlan tag 5 desc vlan5
config vlan vid 5 add tagged 1
config mgt_vlan enable 5
(тут перетаскиваю на своей машине IP 192.168.0.4/24 с eth1 на eth1.5 и соединяюсь заново уже с VLAN 5)
Код:
save
Передёргиваю питание, запускаю на машине wireshark на eth1, захожу телнетом - уже тут видны странности:
Код:
DES-2108:>show fdb port 1
Command: show fdb port 1
DYNAMIC MAC SEARCH LIST:
Idx Port VID MAC Address
-----------------------------------
001 1 1 00804819fff5
002 1 5 00804819fff5
При этом wireshark не показал ни одного пакета без тега или с тегом 1, однако в таблице откуда-то выполз VID 1. При этом через SNMP таблица BRIDGE-MIB::dot1dTpFdbTable нормально не читается:
Код:
$ snmpwalk -v1 -c public 192.168.0.1 BRIDGE-MIB::dot1dTpFdbTable
BRIDGE-MIB::dot1dTpFdbAddress.'.─H..У' = STRING: 0:80:48:19:ff:f5
BRIDGE-MIB::dot1dTpFdbAddress.'.─H..У' = STRING: 0:80:48:19:ff:f5
Error: OID not increasing: BRIDGE-MIB::dot1dTpFdbAddress.'.─H..У'
>= BRIDGE-MIB::dot1dTpFdbAddress.'.─H..У'
Приходится добавлять опцию -Cc (ещё добавил -OX для более красивого вывода):
Код:
$ snmpwalk -v1 -c public -Cc -OX 192.168.0.1 BRIDGE-MIB::dot1dTpFdbTable
BRIDGE-MIB::dot1dTpFdbAddress[STRING: 0:80:48:19:ff:f5] = STRING: 0:80:48:19:ff:f5
BRIDGE-MIB::dot1dTpFdbAddress[STRING: 0:80:48:19:ff:f5] = STRING: 0:80:48:19:ff:f5
BRIDGE-MIB::dot1dTpFdbPort[STRING: 0:80:48:19:ff:f5] = INTEGER: 1
BRIDGE-MIB::dot1dTpFdbPort[STRING: 0:80:48:19:ff:f5] = INTEGER: 1
BRIDGE-MIB::dot1dTpFdbStatus[STRING: 0:80:48:19:ff:f5] = INTEGER: learned(3)
BRIDGE-MIB::dot1dTpFdbStatus[STRING: 0:80:48:19:ff:f5] = INTEGER: learned(3)
Вообще не совсем понятно, как коммутатор обрабатывает такие запросы по SNMP - в wireshark видны пакеты запросов get-next-request, отличающиеся только request-id, однако get-response на них приходят разные; получается, что SNMP-сервер в коммутаторе ещё сохраняет какое-то состояние между запросами, что в SNMPv1 вроде бы не предусматривалось.
Вход
Регистрация
FAQ
Поиск
