NAV 3.5.5 is now available for download at Launchpad: https://launchpad.net/nav/3.5/3.5.5 This release fixes 17 bugs in NAV 3.5. The log of all changes to the 3.5 series is attached to this message. A binary package for Debian 4 and 5 (Etch and Lenny) will be made available as soon as possible. The Debian package is maintained by Morten Werner Forsbring, on commission From UNINETT. At the same time I would like to apologize for lack of responses to mailing list posts the last few months. We were hoping to have NAV 3.6 ready by now, but everything has been delayed due to the fact that I was away from work for more than two months (beginning around 20th November). Happy NAVing everyone! -- Morten Brekkevold UNINETT
Morten Brekkevold <morten.brekkevold@uninett.no> writes:
A binary package for Debian 4 and 5 (Etch and Lenny) will be made available as soon as possible. The Debian package is maintained by Morten Werner Forsbring, on commission From UNINETT.
Both Etch and Lenny packages are available from the usual places now. I've also update the installation instructions to include Debian Lenny [1]. Please note that security support for Debian Etch was terminated [2] on February 15th 2010. You should strongly consider upgrading from Etch to Lenny. We have documented an upgrade path [3], but this "guide" does not take other packages/services into consideration. As usual, please report problems/bugs/comments to this mailinglist or me directly. :) - Werner [1] http://pkg-nav.alioth.debian.org/ [2] http://www.debian.org/News/2010/20100121 [3] http://pkg-nav.alioth.debian.org/upgrade-path-etch-lenny.html
Hei Morten, Jeg får en del spørsmål fra høyskoler og universitet om hvilken NAV versjon som har den nye arkitekturen dere planlegger? Er det 3.6? Med vennlig hilsen / Best regards, Geir Wendelborg Solutions Consultant ___________________________________________________________ Dell AS Hoffsveien 1D, Postboks 270 Skøyen, 0275 Oslo Sentralbord: +47 67116800 Faks: +47 22928241 Mob: +47 90987646 E-mail: geir_wendelborg@dell.com Dell AS, Hoffsveien 1D, Postboks 270 Skøyen, N-0275 Oslo, Norway Org. nr: NO 861 272 702 MVA
On Tue, 23 Feb 2010 21:09:39 +0100 <Geir_Wendelborg@dell.com> wrote:
Jeg får en del spørsmål fra høyskoler og universitet om hvilken NAV versjon som har den nye arkitekturen dere planlegger? Er det 3.6?
Hi Geir, Please use English when replying to the list. And the answer to your question is: Yes :-) -- Morten Brekkevold UNINETT
Hi Moretn, I'd like to ask if there is a know date when the nav 3.6 should be released? 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? Tahnks Tomas Morten Brekkevold wrote:
On Tue, 23 Feb 2010 21:09:39 +0100 <Geir_Wendelborg@dell.com> wrote:
Jeg får en del spørsmål fra høyskoler og universitet om hvilken NAV versjon som har den nye arkitekturen dere planlegger? Er det 3.6?
Hi Geir,
Please use English when replying to the list.
And the answer to your question is: Yes :-)
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 be released? 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 :) -- Morten Brekkevold UNINETT
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 be released? 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 :)
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:
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
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.
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.
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.
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.
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.
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.
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/ . -- Morten Brekkevold UNINETT
Hi Morten, On 3/4/10 2:14 PM, Morten Brekkevold wrote:
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:
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
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.
I see. We didn't use cisco devices so I didn't know about that. It could be nice to have a possibility to switch of this functionality per the device or per the device type. It is only a suggestion.
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.
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.
Actually the checks through SNMPv1 is not a problem for us. I'll try to find out more about it and make a report on the project Launchpad.
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.
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.
It sounds great. Thanks.
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.
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.
I agree. The IPv6 on management interfaces is not topic of nowadays. The support to collect relevant data is more important now. It was just a idea for the future.
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/ .
I'll be looking forward. Thanks for you time and answers. Tomas Podermanski
On Tue, 09 Mar 2010 10:38:40 +0100 Tomas Podermanski <tpoder@cis.vutbr.cz> wrote:
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.
I see. We didn't use cisco devices so I didn't know about that. It could be nice to have a possibility to switch of this functionality per the device or per the device type. It is only a suggestion.
If you don't use cisco devices, then that is proof that this is a bug. This really shouldn't happen on anything except for Cisco, unless some other vendor is actually using community indexing (which I doubt). I've gone ahead and reported the bug here: https://bugs.launchpad.net/nav/+bug/537166 You can subscribe to the bug report if you register with Launchpad.
Actually the checks through SNMPv1 is not a problem for us. I'll try to find out more about it and make a report on the project Launchpad.
Great :) -- Morten Brekkevold UNINETT
participants (4)
-
Geir_Wendelborg＠dell.com -
Morten Brekkevold -
Morten Werner Forsbring -
Tomas Podermanski