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