NetXMS Support Forum

Добрый день!

Почему-то netxmsd не может получить по SNMP таблицу MAC-адресов с цисковских коммутаторов.

Ситуация такая:
Есть гетерогенная сеть, где присутствуют коммутаторы уровня доступа от разных производителей: Cisco, Nortel, HP. При добавлении нового коммутатора указываю в его свойствах SNMP community, отключаю использование nxagentd и делаю сначала status poll, потом configuration poll и topology poll.

При этом нормально происходит определение имён интерфейсов, списка VLANов, CDP-соседей, но таблица МАС-адресов с коммутатора, судя по всему, не импортируется. В итоге, если сделать поиск устройства (по МАС или IP-адресу), подключенного в цисковский каталист, то в результате получаем "indirectly connected" где-нибудь на нортеловском коммутаторе.

При этом для коммутаторов Nortel (baystack 470) и HP (A5120-48G EI) всё работает хорошо.

Цисковские коммутаторы - C2960G-48TC-L, IOS - 15.0(1)SE1.

Netxms - версии 1.2.4, скомпилирован под FreeBSD  8.3 amd64:

FreeBSD 8.3-RELEASE-p3 #0: Tue Jun 12 00:39:29 UTC 2012     [email protected]:/usr/obj/usr/src/sys/GENERIC  amd64

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

Пришлите пожалуйста результат SNMP WALK для следующих объектов:

.1.3.6.1.2.1.17.1.4.1.2
.1.3.6.1.2.1.17.7.1.2.2.1.2
.1.3.6.1.2.1.17.4.3.1.1

Quote from: Victor Kirhenshtein on December 03, 2012, 12:57:05 PM
Пришлите пожалуйста результат SNMP WALK для следующих объектов:

.1.3.6.1.2.1.17.1.4.1.2
.1.3.6.1.2.1.17.7.1.2.2.1.2
.1.3.6.1.2.1.17.4.3.1.1

Нет объектов с такими OID'ами, говорит:

netxms# /usr/local/bin/snmpwalk -v 2c -c XXXXXXX 192.168.255.196 .1.3.6.1.2.1.17.1.4.1.2

SNMPv2-SMI::mib-2.17.1.4.1.2 = No Such Instance currently exists at this OID

netxms# /usr/local/bin/snmpwalk -v 2c -c XXXXXXX 192.168.255.196 .1.3.6.1.2.1.17.7.1.2.2.1.2

SNMPv2-SMI::mib-2.17.7.1.2.2.1.2 = No Such Object available on this agent at this OID

netxms# /usr/local/bin/snmpwalk -v 2c -c XXXXXXX 192.168.255.196 .1.3.6.1.2.1.17.4.3.1.1

SNMPv2-SMI::mib-2.17.4.3.1.1 = No Such Instance currently exists at this OID

Доступ по SNMP с сервера к коммутаторам точно есть, snmpwalk по другим OID'ам отрабатывает.

Нашел такое примечание на сайте Cisco (http://www.cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/12.2_55_se/configuration/guide/swmibs.html):

The BRIDGE-MIB supports the context of a single VLAN. By default, SNMP messages using the configured community string always provide information for VLAN 1. To obtain the BRIDGE-MIB information for other VLANs, for example VLAN x, use this community string in the SNMP message: configured community string @x.

Если у вас не VLAN 1, поробуйте community@vlan в SNMP WALK.

Quote from: Victor Kirhenshtein on December 04, 2012, 06:46:39 PM
Нашел такое примечание на сайте Cisco (http://www.cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/12.2_55_se/configuration/guide/swmibs.html):

The BRIDGE-MIB supports the context of a single VLAN. By default, SNMP messages using the configured community string always provide information for VLAN 1. To obtain the BRIDGE-MIB information for other VLANs, for example VLAN x, use this community string in the SNMP message: configured community string @x.

Если у вас не VLAN 1, поgробуйте community@vlan в SNMP WALK.

Да, спасибо за ссылку - так snmpwalk отрабатывает по двум OID'ам, по крайней мере (VLAN'ов там куча, действительно, вот вывод для 153-го):

netxms# /usr/local/bin/snmpwalk -v 2c -c XXXXXX@153 192.168.255.196 .1.3.6.1.2.1.17.1.4.1.2

SNMPv2-SMI::mib-2.17.1.4.1.2.1 = INTEGER: 10101
SNMPv2-SMI::mib-2.17.1.4.1.2.4 = INTEGER: 10104
SNMPv2-SMI::mib-2.17.1.4.1.2.5 = INTEGER: 10105
SNMPv2-SMI::mib-2.17.1.4.1.2.6 = INTEGER: 10106
SNMPv2-SMI::mib-2.17.1.4.1.2.7 = INTEGER: 10107
SNMPv2-SMI::mib-2.17.1.4.1.2.9 = INTEGER: 10109
SNMPv2-SMI::mib-2.17.1.4.1.2.10 = INTEGER: 10110
SNMPv2-SMI::mib-2.17.1.4.1.2.11 = INTEGER: 10111
SNMPv2-SMI::mib-2.17.1.4.1.2.12 = INTEGER: 10112
SNMPv2-SMI::mib-2.17.1.4.1.2.15 = INTEGER: 10115
SNMPv2-SMI::mib-2.17.1.4.1.2.16 = INTEGER: 10116
SNMPv2-SMI::mib-2.17.1.4.1.2.17 = INTEGER: 10117
SNMPv2-SMI::mib-2.17.1.4.1.2.18 = INTEGER: 10118
SNMPv2-SMI::mib-2.17.1.4.1.2.19 = INTEGER: 10119
SNMPv2-SMI::mib-2.17.1.4.1.2.20 = INTEGER: 10120
SNMPv2-SMI::mib-2.17.1.4.1.2.23 = INTEGER: 10123
SNMPv2-SMI::mib-2.17.1.4.1.2.24 = INTEGER: 10124
SNMPv2-SMI::mib-2.17.1.4.1.2.25 = INTEGER: 10125
SNMPv2-SMI::mib-2.17.1.4.1.2.27 = INTEGER: 10127
SNMPv2-SMI::mib-2.17.1.4.1.2.29 = INTEGER: 10129
SNMPv2-SMI::mib-2.17.1.4.1.2.31 = INTEGER: 10131
SNMPv2-SMI::mib-2.17.1.4.1.2.32 = INTEGER: 10132
SNMPv2-SMI::mib-2.17.1.4.1.2.36 = INTEGER: 10136
SNMPv2-SMI::mib-2.17.1.4.1.2.38 = INTEGER: 10138
SNMPv2-SMI::mib-2.17.1.4.1.2.39 = INTEGER: 10139
SNMPv2-SMI::mib-2.17.1.4.1.2.40 = INTEGER: 10140
SNMPv2-SMI::mib-2.17.1.4.1.2.43 = INTEGER: 10143
SNMPv2-SMI::mib-2.17.1.4.1.2.44 = INTEGER: 10144
SNMPv2-SMI::mib-2.17.1.4.1.2.45 = INTEGER: 10145
SNMPv2-SMI::mib-2.17.1.4.1.2.48 = INTEGER: 10148
SNMPv2-SMI::mib-2.17.1.4.1.2.64 = INTEGER: 5001

netxms# /usr/local/bin/snmpwalk -v 2c -c XXXXXX@153 192.168.255.196 .1.3.6.1.2.1.17.4.3.1.1

SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.153.136.63.220 = Hex-STRING: 00 03 99 88 3F DC
SNMPv2-SMI::mib-2.17.4.3.1.1.0.4.118.224.203.144 = Hex-STRING: 00 04 76 E0 CB 90
SNMPv2-SMI::mib-2.17.4.3.1.1.0.21.93.0.126.126 = Hex-STRING: 00 15 5D 00 7E 7E
SNMPv2-SMI::mib-2.17.4.3.1.1.0.21.93.0.126.127 = Hex-STRING: 00 15 5D 00 7E 7F
SNMPv2-SMI::mib-2.17.4.3.1.1.0.21.199.54.244.192 = Hex-STRING: 00 15 C7 36 F4 C0
SNMPv2-SMI::mib-2.17.4.3.1.1.0.22.118.5.23.179 = Hex-STRING: 00 16 76 05 17 B3
SNMPv2-SMI::mib-2.17.4.3.1.1.0.24.254.125.160.80 = Hex-STRING: 00 18 FE 7D A0 50
SNMPv2-SMI::mib-2.17.4.3.1.1.0.28.192.149.94.187 = Hex-STRING: 00 1C C0 95 5E BB
SNMPv2-SMI::mib-2.17.4.3.1.1.0.28.196.216.212.22 = Hex-STRING: 00 1C C4 D8 D4 16
SNMPv2-SMI::mib-2.17.4.3.1.1.0.31.208.162.112.128 = Hex-STRING: 00 1F D0 A2 70 80
SNMPv2-SMI::mib-2.17.4.3.1.1.0.37.131.95.232.47 = Hex-STRING: 00 25 83 5F E8 2F
SNMPv2-SMI::mib-2.17.4.3.1.1.0.38.24.68.188.218 = Hex-STRING: 00 26 18 44 BC DA
SNMPv2-SMI::mib-2.17.4.3.1.1.0.64.140.133.235.155 = Hex-STRING: 00 40 8C 85 EB 9B
SNMPv2-SMI::mib-2.17.4.3.1.1.0.64.140.133.235.164 = Hex-STRING: 00 40 8C 85 EB A4
SNMPv2-SMI::mib-2.17.4.3.1.1.0.64.140.133.235.168 = Hex-STRING: 00 40 8C 85 EB A8
SNMPv2-SMI::mib-2.17.4.3.1.1.0.64.140.133.235.192 = Hex-STRING: 00 40 8C 85 EB C0
SNMPv2-SMI::mib-2.17.4.3.1.1.28.111.101.209.148.184 = Hex-STRING: 1C 6F 65 D1 94 B8
SNMPv2-SMI::mib-2.17.4.3.1.1.48.70.154.74.209.193 = STRING: "0F Jяа"
SNMPv2-SMI::mib-2.17.4.3.1.1.60.74.146.196.1.165 = Hex-STRING: 3C 4A 92 C4 01 A5
SNMPv2-SMI::mib-2.17.4.3.1.1.108.240.73.229.165.33 = STRING: "lПIЕ╔!"
SNMPv2-SMI::mib-2.17.4.3.1.1.120.227.181.251.75.101 = STRING: "xЦ╣ШKe"
SNMPv2-SMI::mib-2.17.4.3.1.1.132.201.178.118.133.153 = STRING: "└и╡v┘≥"
SNMPv2-SMI::mib-2.17.4.3.1.1.216.48.98.127.196.51 = Hex-STRING: D8 30 62 7F C4 33
SNMPv2-SMI::mib-2.17.4.3.1.1.240.180.121.1.69.66 = Hex-STRING: F0 B4 79 01 45 42

Для OID .1.3.6.1.2.1.17.7.1.2.2.1.2 всё равно - "no such object":

netxms# /usr/local/bin/snmpwalk -v 2c -c XXXXXXX@153 192.168.255.196 .1.3.6.1.2.1.17.7.1.2.2.1.2
SNMPv2-SMI::mib-2.17.7.1.2.2.1.2 = No Such Object available on this agent at this OID

Похоже придется делать отдельный драйвер для 2960, который будет корректно обрабатывать эту ситуацию.
То, что нет информации под  .1.3.6.1.2.1.17.7.1.2.2.1.2 - это нормально.

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

Хотя, могу попробовать написать драйвер.
Правда, я почитал код - имеющиеся драйверы однотипны, и, насколько я понимаю, необходимость получать таблицу МАС-адресов "поVLANно" приведёт к необхдимости переписки и кода, отвественного за взаимодействие с драйвером?

С таблицами MAC адресов посложнее - сейчас есть только универсальный код. Его надо будет перенести в GENERIC драйвер, добавив новую точку входа, и тогда уже сделать новый для 2960, который будет правильно обрабатывать FDB для конкретной модели. Кстати, а какой драйвер сервер выбрал для 2960 (это видно на закладке Overview в панели Object Details)?

Сейчас сервер выбирает CATALYST-GENERIC, насколько я понимаю, это src/server/drivers/catalyst.

Не очень понял про generic-драйвер "вообще" (я новичок в NetXMS, простите),  это в каком файле посмотреть можно?

GENERIC - это драйвер, который есть всегда. Его код встроен в libnxsrv: src/server/libnxsrv/ndd.cpp. Он используется как базовый класс для всех драйверов и как драйвер по умолчанию.

Quote from: Victor Kirhenshtein on December 10, 2012, 10:15:25 PM
GENERIC - это драйвер, который есть всегда. Его код встроен в libnxsrv: src/server/libnxsrv/ndd.cpp. Он используется как базовый класс для всех драйверов и как драйвер по умолчанию.

Посмотрел, подумал, но пожалуй ndd.cpp я не возьмусь переписывать нахрапом...

P.S. не по теме, но ещё с одной проблемой столкнулся сегодня:  попытался добавить в список устройств коммутатор из состава blade-системы Fujitsu (Fujitsu PY CB Eth Switch 1Gb 36/8+2, Runtime Code 4.12, OS - VxWorks 6.5), отключил использование nxagent, указал SNMP-community. При попытке сделать configuration poll устройство пропало из списка, и на консоли непрерывно стали возникать сообщения "Access denied", хотя сервер доступ по SNMP к устройству получил (sysID определил). Драйвер при этом выбрал GENERIC. Пришлось базу фиксить с помощью nxdbmgr и вычищать все объекты, связанные с этим коммутатором...

Quote from: Victor Kirhenshtein on December 04, 2012, 09:48:11 PMПохоже придется делать отдельный драйвер для 2960, который будет корректно обрабатывать эту ситуацию.

Это похоже особенность не только 2960, но и остальных каталистов. По крайней мере 3750G, 3750 и 35xx ведут себя точно так же.

копнул проблему чуть глубже, вот что нарисовалось:
Cisco не возвращает в dot1dTpFdbTable FDB для всех VLAN'ов потому что это невозможно корректно сделать в принципе.
В dot1dTpFdbTable не предусмотрено отдельного поля для vlan'а к которому принадлежит mac-адрес, а т.к. в разных vlan'ах теоретически могут присутствовать различные устройства с одинаковыми физическими адресами, то FDB, построенная с игнорированием vlan'ов будет некорректна.
Те вендоры, которые выдают в dot1dTpFdbTable все mac-адреса, на самом деле поступают не очень здорово (хотя на первый взгляд это и удобно) (еще хуже то, что известны случаи подобных упрощений и обобщений в реальной, используемой при коммутации, FDB).
Ситуация совпадения mac'ов в мирное время крайне маловероятна, однако ж если кто-то решил в сети развлечься (или китайский рабочий накосячил) может иметь место быть.

В циске ситуацию разрулили snmp-контекстами. На свитче для каждого vlan'а определен контекст vlan-XXX (где XXX - vlanid), в случае использования snmp версий ниже 3 обращение к контексту происходит путем добавления @ и его номера к коммунити. т.е. чтобы получить все мак-адреса из 555 vlan'а необходимо

для snmpv3:
snmpwalk -v3 -n vlan-555 -u testuser 172.31.0.1 .1.3.6.1.2.1.17.4.3.1.1

для snmpv2:
snmpwalk -v2c -c testcommunity@555 172.31.0.1 .1.3.6.1.2.1.17.4.3.1.1

единственная претензия к цисковцам, что они не реализовали проприетарный аналог dot1dTpFdbTable, но с блекджеком со всей таблицей мак-адресов и полем под vlan.

ps:
хорошая новость: OID оказывается уже есть, причем не проприетарный. .1.3.6.1.2.1.17.4.3 dot1qTpFdbTable
плохая новость: циской не поддерживается.

Спасибо за детальный разбор! Сделал ишшую в баг трекере, чтобы не потерялось: https://www.radensolutions.com/chiliproject/issues/242. В 1.2.7 добавлю поддержку FDB по VLAN'ам.