- Nav-users - lister.unit.no

Re: Announcement: NAV 3.4.2 released
by Tim Chown 12 Sep '08

12 Sep '08

On Wed, Sep 10, 2008 at 11:26:36AM +0200, Morten Brekkevold wrote: > > The SQL script fails because of a typo, i.e. a line was appended after > a line that it was meant to replace, causing an SQL error. > > For more details on this bug, see > https://bugs.launchpad.net/nav/+bug/260330 , which is part of NAV > 3.4.3, slated for release next week. > > You can fix it yourself by simply deleting the first of the two > WHERE-lines, as commented by Kristian Klette here: > https://bugs.launchpad.net/nav/+bug/260330/comments/1 Thanks, that appears to have run fine. -- Tim

1 0

Re: Announcement: NAV 3.4.2 released
by Tim Chown 10 Sep '08

10 Sep '08

On Tue, Sep 09, 2008 at 03:31:00PM +0200, Morten Brekkevold wrote: > On Tue, 9 Sep 2008 13:58:07 +0100 Tim Chown <tjc(a)ecs.soton.ac.uk> wrote: > > > Is there any gotcha to doing a straight aptitude update from a previous > > version (3.4.1) to the new version on a live system? > > There shouldn't be. But make sure to do a "/etc/init.d/apache2 > force-reload" after the upgrade, to make sure Apache/mod_python is > using the new NAV code. The upgrade seemed to work fine. I followed the info about the sql update but got errors: # psql -f 3.4.2.sql manage nav Password for user nav: BEGIN CREATE RULE CREATE RULE CREATE RULE psql:3.4.2.sql:46: ERROR: syntax error at or near "WHERE" at character 1 psql:3.4.2.sql:46: LINE 1: WHERE key='serviceid' AND value=old.serviceid::text; psql:3.4.2.sql:46: ^ ROLLBACK We have psql 8.1, but I assumed the patch was required because we did install 3.4.1 from scratch. The comment in the patch file also says "NAV 3.4.1 and 3.4.1 were shipped with a manage.sql..." which I assume should say "NAV 3.4 and 3.4.1". Is the patch failing because we don't need it, or some other issue? :) Thanks, -- Tim

2 1

Re: Announcement: NAV 3.4.2 released
by Tim Chown 09 Sep '08

09 Sep '08

Hi, Probably an unecessary question, but we'd like to be sure... Is there any gotcha to doing a straight aptitude update from a previous version (3.4.1) to the new version on a live system? We have deb http://pkg-nav.alioth.debian.org/debian/ etch local as our source. Thanks, -- Tim

3 2

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

Feature request hidden in Launchpad?
by Stokkenes Vidar 05 Sep '08

05 Sep '08

Hello, I might be the one not searching good enough, but I couldn't really find anywhere to put a feature request on Launchpad. As I've seen quite a few suggestions on stuff on this list, I might as well give it a shot here. One of many NAV features we've found handy, is the Module State warning feature. What I really don't understand, is why NAV haven't built in a PSU State warning system. There are numerous of MIBs under the CISCO-ENVMON-MIB <http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=2&mibName…> tree for this task. A Cisco specific MIB for the general PSU status would be "1.3.6.1.4.1.9.9.13.1.5.1", and would give you the following result on: Cisco 65XX series: SNMPv2-SMI::enterprises.9.9.13.1.5.1.2.1 = STRING: "Power Supply 1, WS-CAC-2500W" SNMPv2-SMI::enterprises.9.9.13.1.5.1.2.2 = STRING: "Power Supply 2, WS-CAC-2500W" SNMPv2-SMI::enterprises.9.9.13.1.5.1.3.1 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.13.1.5.1.3.2 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.13.1.5.1.4.1 = INTEGER: 2 SNMPv2-SMI::enterprises.9.9.13.1.5.1.4.2 = INTEGER: 2 Cisco 35XX series: SNMPv2-SMI::enterprises.9.9.13.1.5.1.2.1003 = STRING: "Sw1, PS1 Normal, RPS NotExist" SNMPv2-SMI::enterprises.9.9.13.1.5.1.3.1003 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.13.1.5.1.4.1003 = INTEGER: 2 Cisco 45XX series: SNMPv2-SMI::enterprises.9.9.13.1.5.1.2.1 = STRING: "Power Supply 1" SNMPv2-SMI::enterprises.9.9.13.1.5.1.2.2 = STRING: "Power Supply 2" SNMPv2-SMI::enterprises.9.9.13.1.5.1.3.1 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.13.1.5.1.3.2 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.13.1.5.1.4.1 = INTEGER: 2 SNMPv2-SMI::enterprises.9.9.13.1.5.1.4.2 = INTEGER: 2 The status integers for the power supply MIB are pretty much alike the Module State warning integers, so implementing such a feature wouldn't be a big problem. And the graphical interface/warning would look pretty much the same as the Module State thing when browsing a device, or as a Power Supply failure on the Status page.. I don't know about others, but I like to get a warning when my power equipment fails, or we're having a power failure :) Any thoughts? ------------------------------------------------------ Vidar Stokkenes Konsulent Nettverk Seksjon for nettverk og telekom HN IKT - Tromsø Tlf: 76 16 61 87 / 77 66 99 55 Mobil: 95 87 99 42 e-post: vidar.stokkenes(a)hn-ikt.no<mailto:vidar.stokkenes@hn-ikt.no> [cid:image001.png@01C90F3D.BA283A30]

3 4

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

05 Sep '08

On Fri, Sep 05, 2008 at 09:42:44AM +0200, Morten Brekkevold wrote: > > > > # The e-mail address of the NAV system administrator. All cron error > > # messages will be sent to this address. > > ADMIN_MAIL=systjc(a)ecs.soton.ac.uk > > > > I suggest you add another option > > > > CRON_MAIL=.... > > > > so you can still have an admin contact on the NAV system/web view, but > > direct cron stuff easily to nowhere. Or maybe a variable for just the > > Cricket cron outputs if NAV cron output is useful :) > > The ADMIN_MAIL setting has no relation to what is displayed as a > contact anywhere on the NAV web; that's just regular HTML configured > by the administrators in the webfront config/template files. > > The point of ADMIN_MAIL is to have something to fall back to if all > other methods of getting attention fail. Ah my bad, I assumed the contact info that by default is bottom right of the NAV home was take from there. But it isn't :) > One thing you can do is edit /etc/nav/cron.d/cricket and redirect > everything from the collect-subtrees cricket command to /dev/null and > then run "nav restart cricket" to reinstall the cron snippet into > navcron's crontab. > > If you do that, you can still find cricket's messages in its log > files. It's default loglevel is more verbose than just error > messages, so you'd either have to grep the logs for errors or adjust > the loglevel in cricket-conf.pl. Nice tip, thanks. -- Tim

1 0

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

05 Sep '08

On Thu, Sep 04, 2008 at 10:11:39AM +0200, Morten Brekkevold wrote: > On Thu, 28 Aug 2008 15:18:12 +0100 Tim Chown <tjc(a)ecs.soton.ac.uk> wrote: > > >> 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 :) > > There is no recommended way, really. Cricket is a noisy fellow, > complaining about every little thing that annoys it, and since it > normally runs every five minutes, it annoys the heck out of many a > sysadmin during the course of a day. Now I realise why it is called cricket. Nothing to do with the game :) > Most installations I've run into either direct cron-mail from Cricket > into /dev/null, or put it into a mailbox they check less often than > their inbox. It's output is not all terribly useful. OK, so a suggestion is that in nav.conf you currently have (for example): # The e-mail address of the NAV system administrator. All cron error # messages will be sent to this address. ADMIN_MAIL=systjc(a)ecs.soton.ac.uk I suggest you add another option CRON_MAIL=.... so you can still have an admin contact on the NAV system/web view, but direct cron stuff easily to nowhere. Or maybe a variable for just the Cricket cron outputs if NAV cron output is useful :) > > Is there a recommended way to configure NAV to not poll our 3750 > > stacks for temp data? > > You could re-profile them and see whether NAV notices that they don't > support that OID anymore. Thanks for the explanation, it does help a lot to understand it, though reprofiling had no effect :/ > > A week ago I knew far less about OIDs and I think I was better for > > it :) > > Welcome to the wonderful world of SNMP ;) We've just started looking at our 1230 series Cisco APs and including them in NAV. Fun with OIDs there too. I think that will be for a separate mail later ;) Thanks again for the excellent support/explanations. -- Tim

2 1

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

04 Sep '08

On Thu, Sep 04, 2008 at 10:52:14AM +0200, Morten Brekkevold wrote: > On Thu, 28 Aug 2008 15:31:01 +0100 Tim Chown <tjc(a)ecs.soton.ac.uk> wrote: > > > Regarding the database change offer, we'd be up for trying it if you can > > provide the magic incantation :) > > Sure, these two statements should reset the sysname of all CAM/ARP > entried related to devices which are registered in your NAV at the > moment: > > UPDATE arp SET sysname=n.sysname FROM netbox n WHERE n.netboxid=arp.netboxid; > UPDATE cam SET sysname=n.sysname FROM netbox n WHERE n.netboxid=cam.netboxid; > > You can connect to the database using the psql command line tool, > e.g. "psql manage nav" to connect to the manage database as the nav > user. Use the password from NAV's db.conf. > > I must warn you that these statements can be quite slow, depending on > the number of records you have in the two tables. If you have made > any actual device renames during NAV's runtime, these devices' records > will also be falsified by these statements. We have only been running for a month or so on 15 stacks, so it was actually very quick :) manage=> UPDATE arp SET sysname=n.sysname FROM netbox n WHERE n.netboxid=arp.netboxid; UPDATE 12824 manage=> UPDATE cam SET sysname=n.sysname FROM netbox n WHERE n.netboxid=cam.netboxid; UPDATE 68724 As far as we can see, all the old historic IP-names are now updated to names, which has added consistency to the searches and machine tracker. Many thanks :) > > 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. > > I don't think we want that. We value the historic accuracy of cam and > arp records; we'd rather make sure the machine tracker can search > records across name changes. I agree - the above fix is a useful tip for when a new site like us doesn't have reverse DNS capability in place before firing up NAV, to 'clean' the data. -- Tim

1 0

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

Re: Questions on prefixes and traffic maps
by Tim Chown 22 Aug '08

22 Aug '08

On Wed, Aug 20, 2008 at 07:25:40PM +0200, Vidar Faltinsen wrote: > Tim Chown wrote: > > >When we do add the 6509, how should we enter the prefix/scope information? > >I'm a little confused as to the meaning of static/reserved/scope for the > >'Add prefix' option in the Edit Database. We have maybe 25 vlans and > >subnets, and I assume we need to add them all here. I assume we use > >'scope' for devices we manage? > > When you add a router to NAV with ditto subnets, you simple add the > router (add IP device in Edit Databe) as category GW or GSW (the latter > if it also has layer 2 switch ports, in which a 6509 typically has). > > The subnets will then be autodetected and added to NAV. In cases where > the interfaces are virtual, NAV will also derive the subnet to vlan > mapping, i.e. Interface Vlan10 is a routerport for vlan 10. Hi Vidar, thanks for the explanation. That is indeed what happened when we added our router device(s). The vlan database was also populated and we can still edit scope data via the vlan editor (the two are quite closely coupled :) > You do not have to add a scope to NAV, if you do you do it for one > reason only, to give outer scope information to "the IP address scope - > graphical view" linked from the report tool. Read; > http://metanav.uninett.no/reporttool#ip_address_scope_-_graphical_view Ah, OK, so (for example) we could manually add our campus prefix of 152.78.0.0/16 and the other scopes would then be listed underneath (whether manually entered or autodiscovered)? That's nice. > >Second main question is on the traffic maps. It seems at first glance > >that these show traffic between router interfaces. Is it possible to > >have the traffic map show loads between trunk ports that connect switch > >stacks? That would be very useful for us if it could be configured. > > The traffic map of today is soon to be replaced with a new one, and this > will be able to show the traffic between trunk ports. When I say soon, > hopefully 3.5 in September, it may not be feature complete at that time, > but hopefully this will be in place. That would be really useful :) > You may be able to see the trunk port traffic on todays map as well if > you drill down on a relevant subnet to see the layer 2 structure. The information as you imply is all there, 'just' need a view of it. Certainly enjoying exploring NAV, it's very useful so far, many thanks for all the team's work on it :) -- Tim

1 0

Bugtracker moved from Sourceforge to Launchpad
by Kristian Klette 20 Aug '08

20 Aug '08

Hi all NAVers! Our new bugtracker is located at http://bugs.launchpad.net/nav All of the bugs that were reported on Sourceforge was imported, so all the data should be there. To simplefy bug-reporting for developers and other console-junkies, the nav-tip[0] now has a small tool called nav_bug.py in the contrib folder. Add this tool to your path and run nav_bug.py --help for more info about how to use the tool. I hope you all will enjoy using a more up-to-date bugtracker, and help us making NAV even better! - Kristian Klette [0]: http://metanav.uninett.no/hg/default -- Mvh Kristian Klette «Programs for sale: Fast, Reliable, Cheap: choose two.»

2 1

Questions on prefixes and traffic maps
by Tim Chown 20 Aug '08

20 Aug '08

Hi NAVers, We've just installed NAV on a Debian4 r3 system for our department network that has a core Cisco 6509 and a number of satellite 3750 stacks and Cisco wireless APs. At present our 3750 stacks are switching only, and thus in NAV we entered them as SW devices (Layer 2, many vlans). So far in NAV we have enabled monitoring of our 3750 stacks, but not yet the core 6509, so we only have layer 2 info/configs. We're getting data now for our switch port use, and cricket showing info on packet rates through the ports. When we do add the 6509, how should we enter the prefix/scope information? I'm a little confused as to the meaning of static/reserved/scope for the 'Add prefix' option in the Edit Database. We have maybe 25 vlans and subnets, and I assume we need to add them all here. I assume we use 'scope' for devices we manage? I notice we cannot add vlans directly; I assume this is implied from the vlan information added in the prefixes? Second main question is on the traffic maps. It seems at first glance that these show traffic between router interfaces. Is it possible to have the traffic map show loads between trunk ports that connect switch stacks? That would be very useful for us if it could be configured. Thanks for any comments or suggestions/tips! -- Tim

2 1

Announcement: NAV 3.4.1 released
by Morten Brekkevold 03 Aug '08

03 Aug '08

NAV 3.4.1 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 available soon. The Debian package is maintained by Morten Werner Forsbring, on commission from UNINETT. We are currently working on migrating NAV from SourceForge.net to Launchpad.net; downloads and issue trackers will be available there once the migration is complete (a separate announcement will be made). We are also working on complete rewrites of AlertEngine and AlertProfiles in Python, thereby ridding NAV entirely of PHP, and almost entirely of Perl. In the process we will also solve some of the basic problems that have plagued alert profiles and alert dispatching for a while. We are hoping to introduce these rewrites in NAV 3.5, scheduled for this fall. Happy NAVing everyone! -- mvh Morten Brekkevold UNINETT

4 7

Problem with Network explorer after upgrading to 3.4/3.4.2 and an issue with c6509-E
by Rikard Stemland Skjelsvik 01 Aug '08

01 Aug '08

Dear all, I have a small issue with Nav after upgrading to 3.4 When i click on the link to Network explorer, i get the following error: HTTP Status 404 - /navAdmin/servlet/navAdmin type Status report message /navAdmin/servlet/navAdmin description The requested resource (/navAdmin/servlet/navAdmin) is not available. Apache Tomcat/5.5 The catalog /var/www/nav/navAdmin only includes .htaccess and an index file that is zero bytes. I am running Debian and i upgraded from a previous version(where network explorer worked) with the apt-get dist-upgrade command. My google-fu came up with a previous poster where Morten Brekkevold replied: NAV contains two Java servlets, vPServer.war and navAdmin.war . These are usually installed in the apache/webapps/ directory, and should be symlinked into Tomcat's webapps directory (wherever your Tomcat installation may be, you don't mention which distro you are using). The catalog /var/www/nav/vPServer, as /var/www/nav/navAdmin, includes only .htaccess and index. A find reveals that both vPServer.war and navAdmin.war is installed in /var/lib/tomcat5.5/webapps/ I would apreciate any help or pointers that could help me solve this problem. As a side note: When adding a Cisco 6509 running s72033_rp-ADVIPSERVICESK9_WAN-M), Version 12.2(33)SXH1, RELEASE SOFTWARE (fc3) to NAV, the cpu on the 6500 went through the roof. This could be a bug, though, i have seen CiscoWorks doing the same before. Any ideas? Is there a way to "nice" NAV on some types of equipment? Regards, Rikard

2 4

questions on MetaNAV about ipv6
by yongkai Jiang 01 Aug '08

01 Aug '08

hi all, I am writing this letter to ask some questions about ipv6 support on MetaNAV. We are investigating into MetaNAV3.4 to manage ipv6 networks. In MetaNAV3.4.0 release note, it says that the system supports ipv6 now. I am a new comer to MetaNAV and know little about SNMP and ipv6 at the moment. So I wonder what does it means by supporting ipv6? Does it means that it has full support on it? eg, can metanav discover an ipv6 device and query related information from it(cpu,load, etc.)? Does it auto-discover the topology in an ipv6 vlan? Can it deal with ipv6 addresses? ... Thanks in advance! Best regards! Sincerely, Richard July 30, 2008

2 1

no such checker: oracle ?
by Stokkenes Vidar 31 Jul '08

31 Jul '08

Hello, As I've recently managed to set up my Siemens SMS gateway properly with the latest gammu, I want to make a profile to monitor our Oracle cluster with NAV and send a notification when its down. While adding the premade "oracle" service to a server (SRV) object, "servicemon" gives me the following error in servicemon.log: [2008-07-31 15:06:38] db.py:getCheckers:226 [Critical] no such checker: oracle [2008-07-31 15:06:38] db.py:getCheckers:226 [Critical] no such checker: oracle [2008-07-31 15:06:38] db.py:getCheckers:226 [Critical] no such checker: oracle [2008-07-31 15:06:38] db.py:getCheckers:226 [Critical] no such checker: oracle [2008-07-31 15:06:38] db.py:getCheckers:226 [Critical] no such checker: oracle [2008-07-31 15:06:38] db.py:getCheckers:226 [Critical] no such checker: oracle [2008-07-31 15:06:38] db.py:getCheckers:226 [Critical] no such checker: oracle [2008-07-31 15:06:38] db.py:getCheckers:226 [Critical] no such checker: oracle [2008-07-31 15:06:38] db.py:getCheckers:226 [Critical] no such checker: oracle [2008-07-31 15:06:38] db.py:getCheckers:226 [Critical] no such checker: oracle [2008-07-31 15:06:38] db.py:getCheckers:226 [Critical] no such checker: oracle This kinda tells me that the premade service called "oracle" is either defunct or just a limbo... But why is it in the list when it doesn't seem to be working? And how can I "recreate" this service in NAV? (I know which ports to probe, etc) I tried to look around with"find" and "locate", but I can't seem to find the location where I can add/edit these premade services (http/https/ssh/dc/oracle/dns, etc) Any help would be appreciated! ------------------------------------------------------ Vidar Stokkenes Konsulent Nettverk Seksjon for nettverk og telekom HN IKT - Tromsø Tlf: 76 16 61 87 / 77 66 99 55 Mobil: 95 87 99 42 e-post: vidar.stokkenes(a)hn-ikt.no<mailto:vidar.stokkenes@hn-ikt.no> [cid:image001.png@01C8F31F.82A227E0]

1 0

NAV and firewalls
by Fredrik Holmberg 24 Jul '08

24 Jul '08

Hi everyone, Testing NAV (3.4.0) in a LAN environment where there are no internal/managed routers (managed by ISP), only firewalls (Check Point NGX R61) connecting the subnets. What is considered best practice when adding these devices in NAV? Can all the features be available in such a LAN setup (prefix matrix report, netmap/traffic map, "connected to" column in switch port report, machine tracker etc.)? The rest of the networking equipment (switches, servers) is up and running. Kind regards, Fredrik Holmberg

2 1

Some questions about Edit Database
by Christian Baensch 24 Jul '08

24 Jul '08

Hello, we´re actually testing your magnificant nms and we´ve some questions about "Edit Database" a) Is it possible to add/edit the default categories for the ip devices; e.g. "category=gsw" or "category=wlan" b) Is it possible to change the "Function" description of an aviable ip device; e.g. Funcion=Network Thanks in advance and with kind regards from germany!! 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

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nav-users