NAV is an acronym for Network Administration Visualized. It is an advanced software suite to monitor large computer networks. It automatically discovers network topology, monitors network load and outages, and can send alerts on network events by e-mail and SMS, allowing for flexible configuration of alert profiles.
NAV development began at the Norwegian University of Science and Technology (NTNU) in 1999. It originated as a collection of scripts used internally at NTNU's ITEA Network group. In 2001 UNINETT became interested in its development, and started funding NAV development at NTNU on behalf of all universities and colleges in Norway.
In 2006 UNINETT assumed the role of NAV development lead, and while most NAV development now occurs at UNINETT, NTNU and a few other universities/colleges in Norway still devote some resources to NAV development.
UNINETT operates the Norwegian research network, on a non-profit basis.
Yes, NAV is licensed under the GNU GPL v2 license.
This site
See NAVDownload.
Short answer: Python and Java.
Long answer: NAV is a modular system consisting of many components (see NAVFeatures for an overview), developed by a number of people over many years (more than 22 people involved since its inception in 1999). Our long term goal is to narrow down the set of programming languages to Python only. So far we have got rid of Perl and PHP and the amount of Java is being reduced.
The databases backend used is PostgreSQL.
NAV is implemented in Python and Java, and should ideally be very portable because of it. But: NAV was primarily written with *NIX systems in mind, and will not easily run on anything else. Although several Linux-isms have been found in the source code, there is also a successful FreeBSD port.
Binaries are available for Debian GNU/Linux and several RPM-based Linux distributions. There is also a virtual appliance available.
Se NAVInstallation for more information.
It is hard to give an absolute answer. It depends heavily on the size of the network you are managing.
To give you an idea, here are some NTNU-specific data (from 2005):
| Server | Dual Intel(R) XEON(TM) CPU 1.80GHz, 2GB RAM, 34GB data disk. One network interface. |
| Network | 1082 IP devices monitored: 16 GW, 8 GSW, 206 SW, 561 EDGE, 129SRV, 156 WLAN, 6 OTHER. |
| Traffic | Approximately 2GB of outbound traffic per day is generated from the server running NAV on this network. The inbound traffic is about the same size |
Please note that this is a fairly large network of approximately 20.000 machines.
First; you can do without it and still get SMS messages. Our SMS solution is configurable and can support multiple dispatchers which can include third party SMS suppliers. The most robust solution is still to physically connect a cell phone to your NAV machine. It is the only thing that will work if the network is severely down.
The cell phone can be of “any” brand, as long at it is supported by Gammu. We do however recommend:
See linesofcode.
NAV does not collect network traffic statistics itself, but depends on Cricket (and subsequently RRDTool) for this purpose. NAV automates the process of updating the Cricket configuration tree, based on the set of devices monitored by NAV itself.
The following is a list of dependencies as of NAV 3.9 (sub-dependencies may exist, please refer to the doc of the listed components). The accompanying INSTALL file in the source distribution will always be more up-to-date than this FAQ entry, so you'd be better off looking there.
To build NAV, you need at least the following:
To run NAV, these software packages are required:
The following Java librares are required:
The following python modules are required:
The following python modules are optional:
psycopg2 should be at least version 2.0.8: Earlier versions have bugs that may cause some NAV programs to crash.
If you want to connect a mobile phone to your NAV server and enable SMS alerts in alert profiles, you will need to install the Gammu and python-gammu packages. The SMS damon can use plugins to dispatch SMS'es through other means, but using Gammu as an SMS dispatcher is the default.
If you wish to use the Jabber plugin for alertengine, the python module xmpp is required.
Yes, there are a couple, check the MailingLists page for more info.
Please report bugs using the form on this URL: https://bugs.launchpad.net/nav/+filebug
Make sure you have at least Java 1.5 installed and available on the path. If you have several JDK/JRE installations on your system, you can specify which one to use when running NAV by setting the JAVA_HOME configuration variable in nav.conf.
Verify that the required SNMP and PostgreSQL libraries are available on the Java CLASSPATH.
NAV does not do autodiscovery (although there is a contrib available). You have to seed the database by using the Seed database tool. See seedessentials for more.
ipdevpoll should notice the new netbox within 2 minutes. Be patient.
What exactly is the problem? Please post on nav-users@uninett.no
This means that vlan discovery has failed for some reason. You should check if
navtopology is running (run nav status). If it is running, check the log
file nav/var/log/navtopology.log.
First, check if the box has been registered with Seed database, for instance in netbox report. Second, check with nav status if pping and eventEngine are running. Third, check the log file of pping if it detected the outage. If it did, check the log file of eventEngine if it processed the event. If it did not, check if the event is still present in the eventq: In psql do SELECT * FROM eventq;.
Check if alert enginge is running (with nav status). Check the alert engine log file to see if the event
was processed. Did it cover your user? If not, take a double check on your active profile. You may want to
make a new profile that covers every alarm and see if you get any alerts then.
Because of what Cisco calls community indexing. A 802.1q-enabled Cisco switch will maintain separate forwarding databases for each active VLAN.
Querying the forwarding database for VLAN 20 requires NAV to modify the SNMP community used for communicating with the switch. If the community is public, NAV must use the community public@20.
To obtain all forwarding entries on such a device (i.e. in order to facilitate NAV's machine tracking and topology functionality), NAV must know which VLANs are actively forwarded on the device. Sometimes, NAV will not know this for sure, and will try all VLANs that are allowed to traverse the switch's trunks.
Unfortunately, if NAV tries to query a forwarding table for a VLAN that is not active, the switch will log this as an SNMP authentication failure.
At some point, you might get this error message in the NAV web interface:
Something went wrong Something went wrong while processing your request. Please try again later. If the problems persists, contact your system administrator and/or report a bug on NAV bugtracker.
This means you've found a bug. The bug should be reported at https://bugs.launchpad.net/nav/+filebug , but first you need to produce some more information. There are two ways to do this:
nav.conf configuration file. Please provide this when reporting the bug.nav.conf configuration file, then restarting Apache. If you attempt to reproduce the problem in the web interface, you should now get the real error message and a full traceback/debug dump in your web browser. Please select the copy/paste option on the error message page and put it in your bug report.