On Sun, 28 Feb 2010 15:39:26 +0100 Tomas Podermanski tpoder@cis.vutbr.cz wrote:
Hi Morten, there are several troubles. I tried to describe them below:
- 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
This is a FAQ: http://metanav.uninett.no/navfaq#why_is_my_cisco_switch_s_syslog_full_of_snm...
The question is whether these actually are Cisco switches, or if NAV has done something else wrong in this case.
- 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.
This v1 communication comes from getBoksMacs, not getDeviceData, which is NAV's main SNMP collection engine. It is trying to figure out which VLANs have separate BRIDGE-MIB instances, as per. the FAQ mentioned above. I cannot immediately say why it chooses to use SNMPv1.
As it stands, is that really a problem that causes something to not work for you? Nevertheless, I would consider this a bug that should be reported on Launchpad - especially since it is not in the part of NAV that is being rewritten for the first release of 3.6.
- 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.
I never thought of that, but looking at the code now, I see you are quite right. The gDD plugin uses IPv6-MIB and CISCO-IETF-IP-MIB for IPv6 only, and the old revision of IP-MIB for IPv4 only.
This is being rewritten from scratch for NAV 3.6, though, and in that code we are using both the deprecated and the new tables in the revised IP-MIB for this, so our bases should be covered.
- 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.
That is known. We've never come across a case where people actually use management over IPv6 yet, so we focused IPv6 support on collecting relevant IPv6 data, not on using the IPv6 protocol for communication.
But surely, the need for this will come soon enough.
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.
There will be a beta available of NAV 3.6 at some point, it will be announced here in the mailing list. Our source code repositories are available at http://metanav.uninett.no/hg/ .