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: Java, Python, Perl and PHP.
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). One ambition with NAV 3 has been to narrow down the set of programming languages to Python and Java, but due to lack of resources, some Perl and PHP components still remain.
The databases backend used is PostgreSQL.
NAV is implemented in Java, Python, Perl and PHP, 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 (etch and sarge) and several RPM-based Linux distributions. More specifically, Morten Werner Forsbring of the University of Oslo maintains the Debian package on commission from UNINETT, and aims to have this package accepted in the next official release of Debian. Alexander Krapivin voluntarily maintains an RPM package, which should be compatible with several RPM-based Linux distributions such as CentOS, SuSE and RedHat Enterprise Linux.
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.5 (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 Perl modules are required:
The following Java librares are required:
The following python modules are required:
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 our bugtracker at Launchpad
Make sure you have at least Java 1.4 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 Edit database tool. See seedessentials for more.
getDeviceData should notice the new netbox within 5 minutes, and will then classify the new box in terms of OIDs supported. This can be seen from the netbox report, https://yournav/report/netbox, under SNMP. Alternatively, you can do a select in the database:
SELECT oidkey, descr FROM snmpoid JOIN netboxsnmpoid USING (snmpoidid) JOIN netbox USING(netboxid) WHERE sysname='insert sysname';
You can also look in the getDeviceData.log file; grep after the name of the new netbox.
You should add the new type to NAV. Note that metanav keeps a Wiki-list of new types, so you may bulk in data found here.
What exactly is the problem? If you have added the type for the switch, check which OIDs NAV thinks it supports by looking at the report for the netbox under SNMP. For details on NAV support, and how to check, have a look at CertifyEquipment.
This means that vlan discovery has failed for some reason. You should check if
networkDiscovery is running (run nav status). If it is, check the log files of networkDiscovery under nav/var/log/networkDiscovery/.
First, check if the box has been registered with Edit 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.