NetXMS Support Forum

Спасибо за внимание к проблеме!

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

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

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