Nav-users

nav-users@lister.sikt.no

2 participants
1380 discussions

Start a nNew thread

ipdevpoll UnicodeDecodeError when storing unidentified LLDP neighbors
by Bruno Galindro da Costa 29 Jul '13

29 Jul '13

This bug still occurs with NAV 3.14.15926-1 https://bugs.launchpad.net/nav/+bug/968917 -- Att. Bruno Galindro da Costa

2 1

Cricket Graph missing
by Orzakiewicz Cedric 29 Jul '13

29 Jul '13

Hi, I have added a new device (switch) in NAV. Unfortunately, I don't see any graph corresponding to this device in Cricket module (while I still see the different graphs for other devices that are also switches). What can I do to get the graphs of this new device ? I had a look everywhere in NAV, checked the documentation, but I did not see anything about that. Thank you.. Cédric.

3 7

Restrict mcc netbox interfaces
by Bruno Galindro da Costa 26 Jul '13

26 Jul '13

Hi! Unfortunately my network devices are very slow to anwser snmp get-bulk requests, causing cricket process run indefinitely. Is it possible to implemment a new feature to restrict the number of interfaces generated by mcc.py? So, I can tell to mcc.py to only generate trunk interfaces config. Searching in source code, i've found this piece of code. I think the bold line that must be upgraded to provide this feature: def create_interface_config(netbox, targetdir, module): """Create config for this netbox and store it in targetdir returns: a list of containers """ LOGGER.info("Creating config for %s" % targetdir) config = CONFIG[module] * interfaces = netbox.interface_set.select_related('netbox').filter(* * **config['filter']).distinct().order_by('ifindex')* Until this feature can be applyed, is there any workarround that I can do to acomplish that? All of my switches trunk ports is standardized to be in the last ports (22 to 26 and 44-48)... -- Att. Bruno Galindro da Costa

2 3

Announcement: NAV 3.14.159265 released
by Morten Brekkevold 02 Jul '13

02 Jul '13

NAV 3.14.159265, another maintenance release of the endless NAV 3.14 series is now available for download at Launchpad: https://launchpad.net/nav/3.14/3.14.159265 This release rolls back changes to the camlogging system that were made previously in the 3.14 series.. These changes caused cam records to be created erroneously and also a massive load increase on the server NAV is running on. See LP#1195206 for more details. ** If you are on 3.14.1592 or 3.14.15926, ** upgrading is HIGHLY recommended. Please report bugs at https://launchpad.net/nav/+filebug Binary packages for Debian will be made available as soon as possible. The Debian package is maintained by Morten Werner Forsbring, on commission from UNINETT. Happy NAVing everyone! -- Morten Brekkevold UNINETT AS

2 1

NAV dashboard teaser
by John-Magne Bredal 01 Jul '13

01 Jul '13

Hi NAV'ers! In an effort to break the silence on this mailing-list I decided to post a teaser of what we're working with regarding new layout and user friendlyness. The attached image shows the last iteration of the front page. The plan is to make it customizable for the individual user by provinding a set of "Navlets" or widgets that show updated information and provide shortcuts to NAV's tools. A user can add, remove and reorder Navlets to create the dashboard he wants. Some of the Navlets are individually configured, for instance to display the graph or the status the user finds most interesting. A Navlet can be set to auto-update periodically so that the dashboard can be used on always on screens in network monitoring environments. This is a work in progress. Any input from you is appreciated! NB: The logo is a placeholder. Regards -- John-Magne Bredal UNINETT AS

3 4

mcc.py fails due to inconsistency in database
by Ingeborg Hellemo 25 Jun '13

25 Jun '13

Trying to upgrade to 3.14.15926 mcc.py fails somwhere in the middle of moving switch-ports to ports with File "/usr/local/nav/bin/mcc.py", line 29, in <module> start_config_creation(modules, config) File "/usr/local/nav/lib/python/nav/mcc/utils.py", line 65, in start_config_creation result = mod.make_config(config) File "/usr/local/nav/lib/python/nav/mcc/utils.py", line 49, in wrapper result = f(*args, **kwds) File "/usr/local/nav/lib/python/nav/mcc/interfaces.py", line 52, in make_config results.append(start_config_creation(module, configroot)) File "/usr/local/nav/lib/python/nav/mcc/utils.py", line 49, in wrapper result = f(*args, **kwds) File "/usr/local/nav/lib/python/nav/mcc/interfaces.py", line 111, in start_config_creation dbutils.updatedb(rrddatadir, containers) File "/usr/local/nav/lib/python/nav/mcc/utils.py", line 49, in wrapper result = f(*args, **kwds) File "/usr/local/lib/python2.7/site-packages/django/db/transaction.py", line 217, in inner res = func(*args, **kwargs) File "/usr/local/nav/lib/python/nav/mcc/dbutils.py", line 62, in updatedb category=category) File "/usr/local/lib/python2.7/site-packages/django/db/models/manager.py", line 132, in get return self.get_query_set().get(*args, **kwargs) File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 351, in get % (self.model._meta.object_name, num, kwargs)) nav.models.rrd.MultipleObjectsReturned: get() returned more than one RrdFile -- it returned 2! Lookup parameters were {'category': 'port-counters', 'key': 'interface', 'value': '2001418'} I guess there is some inconsistency in database, but where and after what shall I look? --Ingeborg

2 5

Announcement: NAV 3.14.15926 released
by Morten Brekkevold 20 Jun '13

20 Jun '13

NAV 3.14.15926, another maintenance release of the endless NAV 3.14 series is now available for download at Launchpad: https://launchpad.net/nav/3.14/3.14.15926 This release fixes the following reported issues: * LP#1177754 (SRV and OTHER category devices have no uplinks) * LP#1185786 (maintengine.py crashes on any maintenance task with room or location components) * LP#1185848 (VLAN topology direction is wrong in cases of multiple links between two devices) * LP#1186193 (Cricket collects statistics from EDGE switches in NAV 3.14.1592) Please report bugs at https://launchpad.net/nav/+filebug Binary packages for Debian will be made available as soon as possible. The Debian package is maintained by Morten Werner Forsbring, on commission from UNINETT. Happy NAVing everyone! -- Morten Brekkevold UNINETT AS

1 0

Announcement: NAV 3.14.1592 released
by Morten Brekkevold 30 Mai '13

30 Mai '13

NAV 3.14.1592, another maintenance release of the endless NAV 3.14 series is now available for download at Launchpad: https://launchpad.net/nav/3.14/3.14.1592 This release changes some aspects of how Cricket is configured to collect traffic statistics, so we have added a couple of important upgrade notes: * The Cricket trees `switch-ports` and `router-interfaces` have been consolidated into a single `ports` tree, where all physical ports' traffic stats now also are collected. After running the usual `syncdb.py` command, you should run `mcc.py` once manually (as the navcron user) to ensure the Cricket config tree is updated right away. When everything is up and running again, you can optionally delete the `switch-ports` and `router-interfaces` directories from your `cricket-config` directory, as they are no longer used by NAV. * NAV now supplies its own `subtree-sets` configuration to Cricket. If you have made manual changes to your Cricket collection setup and/or this file, you may need to update your setup accordingly. This release fixes the following reported issues: * LP#1165193 (Prefix Matrix Doesn't Handle HSRP) * LP#1165206 (ARP Entries on HSRP Subnets are Double Counted) * LP#1169553 (Consolidate switch-ports, router-interfaces and physical port traffic statistics in Cricket) * LP#1169837 (servicemon debug logs no matter what the log level is set to) * LP#1169872 (VRRP/HSRP plugin is not enabled by default) * LP#1169986 (ipdevpoll spins in its tracks and doesn't reconnect on database connection loss) * LP#1170221 (Subnet matrix crashes with AttributeError when only one scope prefix is registered) * LP#1170291 (Mac search + DNS crashes with AttributeError in NAV 3.14.159) * LP#1170329 (eventengine dies on loss of database connection) * LP#1170374 (Alertengine dies on loss of database connection) * LP#1170634 (The SMS daemon dies when database connection is lost) * LP#1172204 (Device history crashes with NameError on invalid date input) Please report bugs at https://launchpad.net/nav/+filebug Binary packages for Debian will be made available as soon as possible. The Debian package is maintained by Morten Werner Forsbring, on commission from UNINETT. Happy NAVing everyone! -- Morten Brekkevold UNINETT AS

2 2

mod_python error and InterfaceError: connection already closed
by Ted 08 Mai '13

08 Mai '13

I've been running NAV (3.14.15 on Debian appliance) for a few weeks without any issues but recently I started getting errors when running the Layer 2 trace tool. I tried upgrading but I guess the package for Debian hasn't been released yet... Any suggestions would be appreciated. Thank you. The error message is below: MOD_PYTHON ERROR ProcessId: 1023 Interpreter: 'nav-appliance.uninett.no' ServerName: 'nav-appliance.uninett.no' DocumentRoot: '/usr/share/nav/htdocs' URI: '/l2trace/' Location: '/' Directory: None Filename: '/usr/share/nav/htdocs/l2trace' PathInfo: '/' Phase: 'PythonHandler' Handler: 'django.core.handlers.modpython' Traceback (most recent call last): File "/usr/lib/python2.6/dist-packages/mod_python/importer.py", line 1537, in HandlerDispatch default=default_handler, arg=req, silent=hlist.silent) File "/usr/lib/python2.6/dist-packages/mod_python/importer.py", line 1229, in _process_target result = _execute_target(config, req, object, arg) File "/usr/lib/python2.6/dist-packages/mod_python/importer.py", line 1128, in _execute_target result = object(arg) File "/usr/lib/pymodules/python2.6/django/core/handlers/modpython.py", line 228, in handler return ModPythonHandler()(req) File "/usr/lib/pymodules/python2.6/django/core/handlers/modpython.py", line 208, in __call__ signals.request_finished.send(sender=self.__class__) File "/usr/lib/pymodules/python2.6/django/dispatch/dispatcher.py", line 162, in send response = receiver(signal=self, sender=sender, **named) File "/usr/lib/pymodules/python2.6/django/db/__init__.py", line 84, in close_connection conn.close() File "/usr/lib/pymodules/python2.6/django/db/backends/__init__.py", line 70, in close self.connection.close() InterfaceError: connection already closed

2 1

Bruk av NAV og uheldige konsekvenser for Cisco-utstyr
by Inge Bjørnvall Arnesen 07 Mai '13

07 Mai '13

Hei, Takk for et glitrende program! Jeg har testkjørt dette hos oss i et halvårs tid, men sliter med et alvorlig og et mindre alvorlig problem: 1: Cisco ASA. Vi bruker denne serien ganske mye og i de fleste tilfeller fungerer NAV bra. Mot bokser som har 10-30 VLAN ser det ut til å gå som det skal. På bokser med mange VLAN (128+) får vi derimot en feil på SNMP-tasken hvert kvarter: 2013-05-02T11:27:18.100301+02:00 XXX <164>May 02 2013 11:27:18: %ASA-4-711004: Task ran for 150 msec, Process = snmp, PC = 8c4b7c8, Call stack = 2013-05-02T11:27:18.100301+02:00 XXX <164>May 02 2013 11:27:18: %ASA-4-711004: Task ran for 150 msec, Process = snmp, PC = 8c4b7c8, Call stack = 0x08B70783 0x08B50B1D 0x08B4F87C 0x08063B63 2013-05-02T11:27:18.100311+02:00 XXX <164>May 02 2013 11:27:18: %ASA-4-711004: Task ran for 152 msec, Process = snmp, PC = 8b77990, Call stack = 2013-05-02T11:27:18.100311+02:00 XXX <164>May 02 2013 11:27:18: %ASA-4-711004: Task ran for 152 msec, Process = snmp, PC = 8b77990, Call stack = 0x08B77990 0x08B76699 0x08B734A9 0x08B75F48 0x08B50E0E 0x08B4F87C 0x08063B63 2013-05-02T11:27:23.113341+02:00 XXX <164>May 02 2013 11:27:23: %ASA-4-711004: Task ran for 150 msec, Process = snmp, PC = 8b7772e, Call stack = 2013-05-02T11:27:23.113417+02:00 XXX <164>May 02 2013 11:27:23: %ASA-4-711004: Task ran for 150 msec, Process = snmp, PC = 8b7772e, Call stack = 0x08B7772E 0x08B7645B 0x08B734A9 0x08B75F48 0x08B50E0E 0x08B4F87C 0x08063B63 Melding ASA-4-711004 gir beskjed om at en task er et "CPU Hog", noe som kan få alvorlige konsekvenser tradisjonelle ASA-bokser (pre-SMP). Når dette skjer, vil nodene i ASA-klyngen oppleve pakketap og vil nodene vil kunne miste kontakten med hverandre både på inn og utsiden. Det siste ser ut til å være avhengig av den øvrige CPU-belastningen i øyeblikket. 2013-05-02T11:27:28.147580+02:00 XXX <161>May 02 2013 11:27:28: %ASA-1-105005: (Secondary) Lost Failover communications with mate on interface YYY 2013-05-02T11:27:28.147628+02:00 XXX <161>May 02 2013 11:27:28: %ASA-1-105008: (Secondary) Testing Interface YYY 2013-05-02T11:27:28.349692+02:00 XXX <161>May 02 2013 11:27:28: %ASA-1-105009: (Secondary) Testing on interface YYY Passed 2013-05-02T11:27:33.263707+02:00 XXX <161>May 02 2013 11:27:33: %ASA-1-105005: (Secondary) Lost Failover communications with mate on interface outside 2013-05-02T11:27:33.416249+02:00 XXX <161>May 02 2013 11:27:33: %ASA-1-105008: (Secondary) Testing Interface outside 2013-05-02T11:27:33.726430+02:00 XXX <161>May 02 2013 11:27:33: %ASA-1-105009: (Secondary) Testing on interface outside Passed Er dette et kjent problem? Mulig det er tilfeldig, men jeg fikk samme problem når jeg forsøkte noen SNMP bulk-transfers. 2: Cisco switcher. Her får vi en feilmelding fra samtlige switcher hvert kvarter. Meldingen er noe obskur: "2013-05-01T00:04:36.711253+02:00 ZZZ <132>266532: 147851: May 1 00:04:36.638 MEST: %BIT-4-OUTOFRANGE: bit 0 is not in the expected range of 1 to 4094" med hilsen, -- Inge Arnesen

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nav-users