Hello Morten,
To confirm your question, we are using SNMP v2c. I don't believe the issue is with the devices themselves. We currently use another monitoring tool that polls traffic data via SNMP and is reporting correctly on all of the interfaces in question within NAV. If you think it would make sense to still test the snmp results from the nav box command line I'd be happy to try but to incorrect data appears to be isolated to just that server.
As for the neighbor relationships, I'll talk with the rest of our engineering team to see if it'd make sense to move over to lldp instead of cdp.
Thanks for your help!
Brian Mock
________________________________ From: Morten Brekkevold morten.brekkevold@uninett.no Sent: Wednesday, July 24, 2019 01:42 To: Brian Mock Cc: nav-users@uninett.no Subject: Re: New Install Issues
On Tue, 2 Jul 2019 18:50:24 +0000 Brian Mock bmock@getunwired.com wrote:
Some of our devices have interfaces that are showing wildly inaccurate data. It's mostly on any ten gig interfaces but also on a few gig interfaces but they're showing up to 15Tbps of traffic when in reality they're pushing far less than that and the graphs are very broken (see attached screenshots). Most ports on the same devices report properly so it's just a few isolated interfaces.
Interesting. You are, of course, using SNMP v2c?
I did once speak to a customer who had made some live software or hardware upgrades to his Cisco switches, which resulted in erratic traffic counters on _some_ ports, but not all. The erratic counters could be confirmed by issuing SNMP requests from the command line against these devices. I've no idea if they ever opened a Cisco TAC for this issue. You could use something like the `snmpdelta` command line program to verify NAV's reports for the TenGigabitEthernet ports.
The other issue we're running into is devices not showing linked to their neighbors. I tried working through the troubleshooting steps in the docs but the devices don't show up under unrecognized neighbors. On the devices however they show up in the ARP/CAM tables.
CAM is only used to identify _known_ neighbors. Unrecognized neighbors are only registered from CDP and LLDP records that NAV could not identify.
We do have some links that don't support CDP but NAV should still be building these neighbor relationships through the ARP/CAM tables correct?
It can do that, yes, but those aren't necessarily reliable in all cases. In any case, if you have a heterogenous network with other vendors than Cisco, you'd be better off disabling CDP and enabling LLDP on everything. In our experience, mixing CDP and LLDP in a network tends to give strange topology results - especially when mixing in devices that reflect CDP records in their LLDP tables (as some HP devices will do) - and also because CDP packets will pass through non-CDP-speaking devices as if they were invisible.
-- mvh Morten Brekkevold Uninett