Cam Records, Multicast Packets, Broadcast Packets not populating from Cisco Catalyst 1300
I've been using NAV for well over a decade with very few issues... Recently, we've integrated a few Cisco Catalyst 1300 series switches to our network and I do not get cam data from them, nor do I get Multicast or Broadcast packet metrics Looking at ipdevpoll log only see theses warnings: [WARNING zen.pynetsnmp.agentproxy] Packet for x.x.x.x has error: Unknown oid. OIDS: [OID('.1.3.6.1.4.1.9.9.117.1.1.2.1.2.67109505')] [WARNING nav.mibs.power_ethernet_mib.powerethernetmib] [statuscheck 192.168.3.20] device response has bad table index .17.2.99 in POWER-ETHERNET-MIB::pethPsePortTable, ignoring Which seemingly shouldn't cause the issues I'm seeing, but maybe.. Nearly 500 devices on our NAV, and I've never had to do this deep of troubleshooting with it, wondering where to start, and if anyone else has Cisco Catalyst 1300s in their NAV? Corey Thompson
On Mon 30 Mar 2026 at 16:57, Corey Thompson <cthompson@eastgrandforks.net> wrote:
I've been using NAV for well over a decade with very few issues...
Glad to hear it, and sorry for the late reply; your message hit us in the prolonged Norwegian easter holiday :)
Recently, we've integrated a few Cisco Catalyst 1300 series switches to our network and I do not get cam data from them, nor do I get Multicast or Broadcast packet metrics
As far as I know, these are budget switches evolved from Cisco's SMB line of switches - their MIB support is quite different from normal Cisco switches. NAV will identify them as Cisco switches and expect them to have typical Cisco quirks and support typical Cisco MIBs, which they do not. I assume the CAM problem stems from the 1300s not using Cisco's typical community-indexed BRIDGE-MIB hack. IIRC, we made some changes to how PortAdmin works with some of these switches (mainly by selecting a generic, non-Cisco backend for communication). If they really do behave like non-Cisco switches in this regard, there might be room for a workaround also in the collection routines for CAM data. Do these switches support the Q-BRIDGE-MIB, I wonder? Can you debug by trying to walk the Q-BRIDGE-MIB::dot1qTpFdbPort like so: snmpwalk -v2c -c <community> <switch-ip> 1.3.6.1.2.1.17.7.1.2.2.1.2 # Q-BRIDGE-MIB dot1qTpFdbPort
Looking at ipdevpoll log only see theses warnings:
[WARNING zen.pynetsnmp.agentproxy] Packet for x.x.x.x has error: Unknown oid. OIDS: [OID('.1.3.6.1.4.1.9.9.117.1.1.2.1.2.67109505')]
[WARNING nav.mibs.power_ethernet_mib.powerethernetmib] [statuscheck 192.168.3.20] device response has bad table index .17.2.99 in POWER-ETHERNET-MIB::pethPsePortTable, ignoring
Which seemingly shouldn't cause the issues I'm seeing, but maybe..
No, these are different issues. The first warning is actually just an error message from the switch that it does not recognize this OID from the CISCO-ENTITY-FRU-CONTROL-MIB, which NAV expected a Cisco switch to have. The second warning is the switch augmenting its POWER-ETHERNET-MIB::pethPsePortTable with table columns from the CISCO-POWER-ETHERNET-EXT-MIB. NAV has not loaded the latter MIB and will not recognize these extra columns.
Nearly 500 devices on our NAV, and I've never had to do this deep of troubleshooting with it, wondering where to start, and if anyone else has Cisco Catalyst 1300s in their NAV?
If you look in the mailing list archives, one or two other users have reported issues with these lines of switches - so you are not alone. It is hard to properly "fix" this issues in NAV without access to Cisco 1300s to test on, though. -- Sincerely, Morten Brekkevold Sikt – Norwegian Agency for Shared Services in Education and Research
participants (2)
-
Corey Thompson -
Morten Brekkevold