Nav-users August 2008

nav-users@lister.sikt.no

10 participants
16 discussions

Removing HP SwitchStack support from NAV
by Morten Brekkevold 17 Sep '08

17 Sep '08

Hi everyone, for quite some time we've been aware of many fundamental problems with the way support for HP SwitchStacks has been implemented in NAV. HP SwitchStack support was implemented in NAV 3.0 at NTNU, whose HP equipment consisted solely of HP SwitchStacks at that time. The result is code which is heavily biased towards SwitchStacks, to the point that NAV thinks HP devices are always SwitchStacks, no matter what. While we have been pondering alternative ways to model HP SwitchStacks (and consequently, Cisco switch clusters, which are basically the same thing), NTNU has entirely stopped using SwitchStacks. Today, they're experiencing bad side effects of the existing HP-related code in NAV. They're using some HP devices for routing, which NAV cannot handle at all (because of said "HP=SwitchStack only" view). No router ports are collected for these routers. Also, they seem to have many errors in topology information when HP devices are involved. Realizing that NTNU have stopped using SwitchStacks, we also do not know of anyone else who does, so now we are considering dropping support for SwitchStacks entirely from NAV. This way, the existing NAV code can treat HP devices like everything else. Preliminary tests of these changes at NTNU show promising results. So my question to the users of NAV is: Does anyone actually use virtually stacked HP switches? Will anyone miss support for this if removed from NAV? If there is no feedback on this issue, we will likely remove this support starting from NAV 3.5. -- mvh Morten Brekkevold UNINETT

2 3

Announcement: NAV 3.4.2 released
by Morten Brekkevold 09 Sep '08

09 Sep '08

NAV 3.4.2 is now available for download at SourceForge: http://sourceforge.net/projects/nav/ This is a bugfix release, the changelog is attached to this message. Binary packages for Debian will be hopefully be available soon. The Debian package is maintained by Morten Werner Forsbring, on commission From UNINETT. Morten will most likely be on vacation and paternity leave for most of August, so we can't make any promises. FWIW, the Debian 3.4.1 package already contains the fixes for the database issues (manage.sql) mentioned earlier on this list; these issues are the most important ones addressed by the 3.4.2 version. For those upgrading their existing NAV installation, please see the added section about upgrading to 3.4.2 in the attached release notes. Happy NAVing everyone! -- mvh Morten Brekkevold UNINETT

2 1

Re: Device names query
by Tim Chown 04 Sep '08

04 Sep '08

On Thu, Aug 28, 2008 at 03:51:51PM +0200, Morten Brekkevold wrote: > On Fri, 22 Aug 2008 15:43:25 +0100 Tim Chown <tjc(a)ecs.soton.ac.uk> wrote: > > > We since ensured the names resolved, and NAV figured this out, with > > new data being linked to the devices by name, rather than the 'IP name'. > > > > The problem seems to be though that the 'IP name' causes some problems > > when searching on data, e.g. a search based on the new name won't > > match against the old 'IP name'. > > > > Is there a neat way to fix this? e.g. perhaps to simply remove all records > > for the 'IP name' devices? > > You didn't specify what you mean by "data" and searching said "data", > but I will assume you are referring to the Machine Tracker. > > CAM and ARP data are basically stored as logs in the database and used > by the Machine Tracker. Since a CAM/ARP entry in NAV is a historic > record, it retains historic names of the originating devices. > > When you search for a sysname in Machine Tracker, it searches for > records matching that exact/partial name. > > We do however store a reference to the IP device record of the > originating device with each CAM/ARP entry. As long as an IP device > stays registered in NAV, any name changes can be inferred from its > recorded CAM/ARP data. Once the IP device is removed from NAV, the > historic CAM/ARP data remains, but can no longer be used to infer name > changes over time for that particular device. > > So, in short, we could actually add a feature to the Machine Tracker > to find CAM/ARP entries recorded under other names than the one used > in the search form. You're welcome to add this as a wishlist priority > item at https://bugs.launchpad.net/nav if it sounds like something you > would want. I suspect a few people will make the smae 'mistake' that we did, to enter systems by name, but these are converted to IP-names because a reverse lookup is not available. I think this warning was in the small print of the docs, but we were too excited during install and missed it. We'll check out the new bugtracker very soon! Regarding the database change offer, we'd be up for trying it if you can provide the magic incantation :) The switch stacks are: 10.78.64.61 b86-l1-cat1 10.78.64.63 b59-l2-cat1 10.78.64.64 b59-l3-cat1 10.78.64.65 b59-l4-cat1 10.78.64.66 b1-l1-cat1 10.78.64.67 b16-l2-cat1 10.78.64.68 b1-l1-cat2 10.78.64.69 b32-l3-cat1 10.78.64.70 b32-l3-cat2 10.78.64.71 b32-l4-cat1 10.78.64.72 b32-l4-cat2 10.78.64.75 b59-l3-cat2 10.78.64.76 b53-l2-cat1 10.78.64.77 b53-l3-cat1 10.78.64.78 b53-l4-cat1 10.78.64.79 b53-l4-cat2 Some were added after we arranged reverse DNS to work (added a local /etc/hosts entry for convenience) so may not have the problem, but most of them do. If you want to use this essentially as a way to test how you'd add a conversion option to NAV, we're happy to test. -- Tim

3 2

Re: Question on SNMP/tempInlet
by Tim Chown 04 Sep '08

04 Sep '08

On Thu, Aug 28, 2008 at 03:24:58PM +0200, Morten Brekkevold wrote: > On Tue, 19 Aug 2008 17:35:44 +0100 Tim Chown <tjc(a)ecs.soton.ac.uk> wrote: > > > Error and the lines leading up to it: > > [14-Aug-2008 14:40:01 ] Some data is missing for b1-l1-cat1 (). > > [14-Aug-2008 14:40:01*] Received SNMP response with error code noSuchName. OID: 1.3.6.1.4.1.9.9.13.1.3.1.3.1 > > > > And yet if I look at the SNMP OID support listed for the device as > > reported by NAV I see: > > > > b1-l1-cat1 tempInlet 1.3.6.1.4.1.9.9.13.1.3.1.3.1 CISCO-ENVMON-MIB ciscoEnvMonTemperatureStatusValue 21600 > > > > which implies the OID is supported, and is the device inlet temperature. > > > > Is there some additional IOS config required to make this particular data > > available to Cricket? Being new to OIDs, I'm confused as to why it seems > > to be available according to NAV, yet Cricket's getting an error. > > I'm sorry to say that NAV's support for monitoring temperatures on > Cisco devices is hopelessly broken. > > The abovementioned OID refers to the temperature value of a > temperature sensor indexed as 1 in the proprietary CISCO-ENVMON-MIB. > NAV assumes this is the inlet temperature sensor. However, the MIB > definition states that the sensor indices are arbitrarily chosen by > the device, and have no intrinsic meaning. The name of each sensor > must be read from a different column of the temperature table. > > The equipment base this was written for (several years ago) may very > well have had their inlet sensors indexed as 1 in the temperature > table, but recent IOS versions seem to have changed things. > > b1-l1-cat1 may have indexed one of its temperature sensors as 1 during > the initial import into NAV, and then changed its mind at a later > time. That would account for the problem you're having. Thanks for the explanation. What then is the recommended way to suppress errors related to this OID? NAV kindly generates email alerts for errors when querying devices, we just have a few too many related to this OID :) Is there a recommended way to configure NAV to not poll our 3750 stacks for temp data? I see there are config files under Cricket for generic routers and switches with this OID, i.e.: /etc/nav/cricket-config/routers/Defaults /etc/nav/cricket-config/switches/Defaults And also some reference in /etc/nav/cricketoids.txt /etc/nav/cricket-config/config.db It looks like Cricket generates the Defaults file and the config.db each night, while cricketoids.txt is static, but it's not clear to us where those nightly builds are driven from (i.e. where we could remove/suppress the temp entry). It sounds like even using snmpwalk to grab the current indexed value wouldn't help as it is liable to change. The temperature queries work just fine for our Cisco 6509, so ideally we wouldn't want to generically remove temp readings for everything. A week ago I knew far less about OIDs and I think I was better for it :) Thanks, Tim

2 1

Feature request - list more info about SRVs
by Ingeborg Hellemo 02 Sep '08

02 Sep '08

Most of our boxes of type SRV has a "Function" associated with it. This field can be seen via https://.../report/netbox?catid=SRV but not when you browse the individual box. Is it possible to add this field (together with Type, Organisation etc) to the output on <https://.../browse/foo.uit.no/) (and in the new <https://.../ipdevinfo/foo.uit.no/>) ? --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg(a)cc.uit.no (Univ. of Tromsø, Norway)

2 3

Re: Unexpected link into ipdevinfo beta code?
by Tim Chown 28 Aug '08

28 Aug '08

On Thu, Aug 28, 2008 at 03:08:40PM +0200, Stein Magnus Jodal wrote: > On Thu, 2008-08-28 at 15:01 +0200, Morten Brekkevold wrote: > > The simplest way (and least intrusive) way of adding the permission to > > a running NAV installation is to add a new web_access privilege to the > > following regex pattern: ^/ipdevinfo/? > > > > That is also the only useful way to automatically update the > > permissions while upgrading to the next release, Stein Magnus. > > Upgrades should not touch existing privileges, only add new ones. > > On second thought, this is rather obvious and clearly the best way. I've > just changed the trunk.sql upgrade script in the ipdevinfo branch to > insert a new privilege instead of updating the old one. I edited the permissions as suggested, and now have a python error when clicking on the (details) link, so I guess some template file is missing somewhere or can't be read because wider permissions need to be added too? Here's the error: --- start --- Mod_python error: "PythonHandler django.core.handlers.modpython" Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch result = object(req) File "/var/lib/python-support/python2.4/django/core/handlers/modpython.py", line 189, in handler return ModPythonHandler()(req) File "/var/lib/python-support/python2.4/django/core/handlers/modpython.py", line 162, in __call__ response = self.get_response(request) File "/var/lib/python-support/python2.4/django/core/handlers/base.py", line 108, in get_response return callback(request, **param_dict) File "/var/lib/python-support/python2.4/django/views/defaults.py", line 79, in page_not_found t = loader.get_template(template_name) # You need to create a 404.html template. File "/var/lib/python-support/python2.4/django/template/loader.py", line 79, in get_template source, origin = find_template_source(template_name) File "/var/lib/python-support/python2.4/django/template/loader.py", line 72, in find_template_source raise TemplateDoesNotExist, name TemplateDoesNotExist: 404.html --- end --- I guess I should file a bug, but since we have a discussion running... :) -- Tim

2 1

Device names query
by Tim Chown 28 Aug '08

28 Aug '08

Hello again :) Hopefully a quicker query. When we first set up NAV, our networked devices, with their Net10 addresses(*), did not resolve to names, so our database populated with device names that were IP addresses. We since ensured the names resolved, and NAV figured this out, with new data being linked to the devices by name, rather than the 'IP name'. The problem seems to be though that the 'IP name' causes some problems when searching on data, e.g. a search based on the new name won't match against the old 'IP name'. Is there a neat way to fix this? e.g. perhaps to simply remove all records for the 'IP name' devices? Advice welcomed. -- Tim (*) historic reasons :)

2 2

Question on SNMP/tempInlet
by Tim Chown 28 Aug '08

28 Aug '08

Hi, I noticed our cricket cron is generating errors on one SNMP OID, i.e. [14-Aug-2008 14:40:01 ] Retrieved data for b1-l1-cat1 (): U,U,U,U,U,U,U,U [14-Aug-2008 14:40:01 ] Some data is missing for b1-l1-cat1 (). [14-Aug-2008 14:40:01*] Received SNMP response with error code noSuchName. OID: 1.3.6.1.4.1.9.9.13.1.3.1.3.1 Error and the lines leading up to it: [14-Aug-2008 14:40:01 ] Some data is missing for b1-l1-cat1 (). [14-Aug-2008 14:40:01*] Received SNMP response with error code noSuchName. OID: 1.3.6.1.4.1.9.9.13.1.3.1.3.1 And yet if I look at the SNMP OID support listed for the device as reported by NAV I see: b1-l1-cat1 tempInlet 1.3.6.1.4.1.9.9.13.1.3.1.3.1 CISCO-ENVMON-MIB ciscoEnvMonTemperatureStatusValue 21600 which implies the OID is supported, and is the device inlet temperature. Is there some additional IOS config required to make this particular data available to Cricket? Being new to OIDs, I'm confused as to why it seems to be available according to NAV, yet Cricket's getting an error. Thanks :) -- Tim

2 1

Unexpected link into ipdevinfo beta code?
by Tim Chown 28 Aug '08

28 Aug '08

Hi, One of our admins spotted this, not sure if a bug or feature, so not submitted it (yet) to the bug tracker. If you drill down, as an Authenticated User, into Machine Tracker / MAC Search / MAC Search results and then click the (details) link for an interface you are jumped into the /ipdevinfo code, and taken out of the main browse/report code. Since the default permissions for an Authenticated User does not include ipdevinfo, the user gets a permission denied :( I think the (details) link should take you to a link like /browse/b59-l2-cat1/module3/port1846/ rather than one like /ipdevinfo/b59-l2-cat1/module=3/swport=GigabitEthernet3/0/44/ but I assume this has been done in part to test the ipdevinfo beta code? Both pages seems to serve a similar function, one the old way, one (I assume) the new way under development? (The ipdevinfo page doesn't have the Cricket links in place yet) The problem is that Authenticated Users hit this permissions issue, but if we try to add |ipdevinfo| into the web_access permissions, it doesn't seem to resolve the permissions problem. Is that link to the newer stuff intended? If so, how should we correct the permissions problem? Thanks :) -- Tim

3 3

Unsupported SNMP protocol error on Cisco devices
by Christian Baensch 28 Aug '08

28 Aug '08

Hello, we have got some problems to add our Cisco routers to the database: Error: nav.Snmp.UnsupportedSnmpVersionError: Unsupported SNMP protocol version: 0 Unfortunately it happens to all our Cisco routers but not the Cisco switches. This Error Notify already occured in your mailling list with the hint: jar -tf /usr/local/nav/lib/java/SimpleSnmp.jar This is our output: nav:~# jar -tf /usr/local/nav/lib/java/SimpleSnmp.jar META-INF/ META-INF/MANIFEST.MF no/ no/ntnu/ no/ntnu/nav/ no/ntnu/nav/SimpleSnmp/ no/ntnu/nav/SimpleSnmp/SimpleSnmp.class no/ntnu/nav/SimpleSnmp/SimpleSnmpHP.class no/ntnu/nav/SimpleSnmp/TimeoutException.class What can we do? We are running actually NAV 3.3.3 with SunJava 1.4.2. Thanks in advance! With kind regards Christian Baensch -- Christian Baensch, Kommunikationssysteme Friedrich-Alexander-Universitaet Erlangen-Nuernberg, Germany Regionales Rechenzentrum Erlangen (RRZE) christian.baensch(a)rrze.uni-erlangen.de www.rrze.uni-erlangen.de

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nav-users August 2008