Hi Morten, there are several troubles. I tried to describe them below:
1. For some reason the NAV sometimes ask for the invalid community. In some requests nav asks for community like public@3, see the list below:
{ SNMPv1 { GetNextRequest(30) R=44 47.1.2.1.1.2.638 } } { SNMPv1 { GetResponse(35) R=44 47.1.2.1.1.3.1=17 } } { SNMPv1 C=public@3 { GetNextRequest(27) R=1 17.4.3.1.2 } } { SNMPv1 C=public@2 { GetNextRequest(27) R=1 17.4.3.1.2 } } { SNMPv1 C=public@251 { GetNextRequest(27) R=1 17.4.3.1.2 } } { SNMPv1 C=public@240 { GetNextRequest(27) R=1 17.4.3.1.2 } } { SNMPv1 { GetNextRequest(28) R=1 47.1.2.1.1.3 } } { SNMPv1 { GetResponse(35) R=1 47.1.2.1.1.3.1=17 } } { SNMPv1 { GetNextRequest(29) R=2 47.1.2.1.1.3.1 } }
It causes a troubles, because switches always log such request and logs are full of nonsense messages.
W 02/28/10 10:41:13 snmp: SNMP Security access violation from 147.229.255.19 W 02/28/10 10:41:12 snmp: SNMP Security access violation from 147.229.255.19 W 02/28/10 10:41:11 snmp: SNMP Security access violation from 147.229.255.19 ...
2. Although all switches are configured to use SNMPv2 protocol in NAV, some queries are performed through SNMPv1. For example interfaces.ifTable is scanned by V2, but entityMIB.entityMIBObjects.entityLogical.entLogicalTable is scanned by V1. I dumped a communication between nav and one of the switch. The full dump is placed on http://hawk.cis.vutbr.cz/~tpoder/tmp/hp-sklad.txt. As you can see, the communication is performed with V1. At the line "21:43:12.820456" the communication starts with v2c and then continues to line "21:56:10.499674" where the communication is switched back to v1.
... { SNMPv2c { GetNextRequest(29) R=1265 interfaces.ifTable.ifEntry.ifInOctets.4194 } } { SNMPv2c { GetResponse(29) R=1265 interfaces.ifTable.ifEntry.ifInUcastPkts.1=0 } } { SNMPv1 { GetNextRequest(28) R=1 47.1.2.1.1.3 } } { SNMPv1 { GetResponse(35) R=1 47.1.2.1.1.3.1=17 } } { SNMPv1 { GetNextRequest(29) R=2 47.1.2.1.1.3.1 } } ...
3. Some new devices (produced by significant producer) won't support ipv6NetToMediaTable. This part of MIB is obsoleted and moved to ipNetToPhysicalTable (see http://rfc-ref.org/RFC-TEXTS/4293/chapter4.html). Actually NAV don't support ipNetToPhysicalTable. If would be nice if new version of NAV support RFC 4293. It is also problem of the IpAddressTable and other.
4. NAV 3.5 don't support IPv6 address on the management interfaces. Any IPv6 address is just not accepted by Seed Database. But it is not actually a big problem.
Indeed, If there is something how can I help with solving issues I am ready to do it. Also if there will be some beta, or alfa version of code I am interested in it.
Thanks for your time.
Tomas
Morten Brekkevold wrote:
On Wed, 24 Feb 2010 12:57:06 +0100 Tomas Podermanski tpoder@cis.vutbr.cz wrote:
Hi Moretn,
I'd like to ask if there is a know date when the nav 3.6 should bereleased? We started using nav a couple months ago and we meet up some bugs. The bugs were specially related to processes getDeviceData which should be rewritten in the 3.6 (If I have the correct information). I'd like to help with debugging the problem, but I think is a waste of time to do anything of 3.5.x version of nav. Is it a better way to spent some time to describe bugs in 3.5.x or it is better to wait for 3.6 release? What do you think?
Hi Tomas,
We have scheduled the 3.6 milestone for 14th May. If you do have specific problems with getDeviceData, we would like to hear about them
- we want to make sure we don't reproduce mistakes from the past in
the new version :)