After NAV is installed and started (with ´nav start´) NAV does absolutely nothing Put differently, NAV does not autodiscover your network, you have to seed the database with key information. This document explains the requirements (minimum and recommended) that need to be followed in order to get NAV going.

Seeding the database is no longer a process of maintaining text files as it was in NAV 2. All seeding is now done through the web interface, using the Seed Database tool, which operates directly on the contents of NAVdb.

Seed Database has the ability to bulk import data from text files that have a similar format as the old seed text files of NAV 2.

1. You need to define at least one room and at least one location.
2. You must define at least one organization, i.e. the organization that is operationally responsible for your network equipment.
3. All network equipment that you want managed by NAV must be registered (with IP address, category, snmp community, location and organization).
   • NAV has 7 predefined categories, whereof 5 require snmp read support, see details here. If you plan to use the port blocker, Arnold, snmp write communities are also required for your switches.
   • If geographical information is irrelevant to you, you may logically place all equipment in the same room.
   • The same goes for organization, if one unit is operating the whole network, you only define this one.
4. You may also need to register new equipment types. This is necessary in cases where a new box is of an unfamiliar equipment type. Before you add the new type, we advice you to check the EquipmentTypes page first.

If you stick to the minimum requirements the consequences will be:

• You have no information on where equipment is located.
• You have no information on the ownership and usage of the various subnets (more below).

1. Define all physical location where equipment is placed, i.e. network/server rooms and wiring closets.
2. Organize rooms in locations (locations serve as natural geographical domains).
3. Define all relevant organizational entities, i.e. all entities that have their own subnet and/or are responsible for a piece of (NAV defined) equipment.
4. Define the natural usage categories for your subnets (students, staff, administration etc).
5. Adopt the NAV guidelines for configuring router interface description, the prime advantage being that the IP address scope can be mapped to organization and usage.
6. Fill in your IP address scope(s) by using “add prefix” and using the netttype=scope. The scopes are necessary for the “IP address scope - graphical view” to work. You may also use “add prefix” to register reserved IP prefixes.
7. Register new equipment types.
8. Register your IP devices you want managed by NAV. See details below.

Due to dependencies within the database, it is recommended that you register seed data in the following order:

1. Locations
2. Rooms
3. Vendors
4. Types (actually you may find it easier to register new types as NAV encounters when registering a new IP device)
5. Organizations
6. User categories
7. IP devices
8. Services

Registering IP devices is by far the most important and most complex registering process. Some comments:

• For routers (GW / GSW) register the loopback address of the router (this is more robust, as this interface never goes down).
• The categories GW, GSW, SW, EDGE and WLAN require a snmp read community. After you fill in the initial form (or after your bulk submit) an actual snmp poll of the equipment is done. If it does not answer to the given snmp community, the IP device will not be added. In other words, you must have the box up and running, configured with snmp before you can add it to NAV.
• Another requirement is that the IP device is of a known type (sysObjectID). If not, you need to add the type before the new device can be added. A link is provided, so that you can do this before you proceed.
• NAV will automatically register the name of the device based on DNS (NAV does a host lookup on the given IP address). Note that if DNS later is changed NAVs collection system will detect this and update the name. If no DNS record exist, NAV will use the IP address as name. Note that the name configured on the device (i.e. the OID system.sysname) is not used.
• NAV will also derive the serial number from the equipment. If this fails, or if you for some reason want to register something else here, you can do this manually. Registering serial number is not a requirement, but recommended. The serial number is the key parameter to recognize the physical device. Device management bases its track record of physical devices on serial number.
• You may register a text string, function, that describes the IP device further. You may find this most relevant for SRV and OTHER.
• The subcategory field can be used to classify a device within the category. An example is to classify the servers (category SRV) into the subcategories MAIL and DNS. An IP device be a member of one or several subcategories.
• SNMP write community may be registered with the device, it is not an requirement and it is not used by NAV prior to version 3.1. You should register a write community if you are planning to use Arnold, or 3rd party solutions (NTNU uses snmp write a configuration tool for switches that they use)

After an IP device is successfully added to NAV, the collection system will gather data from the device.

Data collection will commence after 2.5 minutes on average and 5 minutes in the worst case. Information on modules and switch ports will be available shortly after this time, depending on the amount of time required for SNMP data gathering; normally just a few seconds. start (after a while) to collect data from the device:

The mactrace process runs 4 times every hour, with 7.5 minutes average wait time after a new devices is added and 15 minutes worst case. Topology- and vlan-discovery runs 10 minutes after each cam logger start, and, given that cam collection completes within 10 minutes, worst-case wait time before NAV has complete information on a new device is about 26 minutes.

As an option you can add seed data using the bulk import option. We recommend this for the initial seeding when you need to input a lot of data.

Tips on bulk importing:

• The format of each bulk import type is documented in the bulk import forms of Seed Database.
• When bulk importing boxes, it is a good idea to split the seed files into smaller pieces. Bulk importing triggers a burst of SNMP queries, and if you are importing a large amount of boxes, your web browser may time out waiting for the web server's reply.
• Some vendors and types are already defined in the initial database. Before importing these, you can check which ones exist by looking at /seeddb/vendor/list and /seeddb/type/list (on web).
• When you bulk import IP devices you will be presented with a list of green, yellow and red lights. Submit and boxes that are green will be added to NAV, the others will not. First make a note of what is missing/wrong with the boxes that have non-green lights and correct this before the next bulk import. Examples:
  • The new box does not repond to snmp.
    ⇒ Check that the community is correct, both in NAV and on the equipment. Check that your NAV server has snmp access to the device.
  • The new box is of an unknown type.
    ⇒ Add the new type to NAV. Tip: The easiest way to do this is to register the first box of the new type manually with “Add IP device”, you are then presented with a link to add the new type. Follow the link and the sysobjectid will already be filled in for you.
• If you are trying to import a nested organizational structure, it may be necessary to import the organization file several times.

We here comment on the other seed topics.

IP devices (typically servers) may have one or more services that you would like to monitor. The service is termed handler. Available handlers are shown in the handler list when you add a service. Some handlers requires extra arguments, they may also have optional arguments. I.e. for imap you have to supply a username/password. This is necessary in order to make a fully qualified test if the service is working properly.

All IP devices are located in a room. A room is recognized by its unique roomid (max 30 characters). A room is on a location and has a description. Further parameters, optional1 - optional4 are generic, the idea being that they can serve a local purpose. They may describe exact room number, telephone number, UTM coordinates etc. By modifying report.conf you can give the optional parameters meaningful names in the room report!

A location is a geographical area containing a number of rooms. The locationid is max 30 characters.

An organization has a name of max 30 characters. It may have a parent organization, we thus support a hierarchical structure. Further it has a description and three generic fields, optional1 - 3. Like for room, the optional field can serve a local purpose, and you can adopt report.conf to reflext this. You may for instance want to register an email address or a contact person etc.

Note that organization in NAV serves three purposes:

1. Each subnet typically hosts an organization (i.e. a physics department subnet). NAV can interpret this if you follow the guidelines for router interface descriptions.
2. Each IP device has an organization that are in charge of operation (registered when adding the IP device).
3. You as a NAV user belong to an organization (although this setting has no effect).

Relevant (along with organization) if you adopt the aforementioned guidelines for configuring router interface descriptions. The usage categories are typically students, staff, administration etc. A maximum of 30 characters are allowed.

All equipment that answers to SNMP supply a system.sysObjectID, this is an identifier for type. When you add a new IP device NAV requires that this is a known type. If not you should add the type. Consult the type page for more information.

• The boolean variable CDP indicates whether the type supports cdp.
• Similarly tftp indicates whether devices of the type can store its config using a tftp server. NAV does not use this for anything, so ignore.
• Set frequency to 3600.

Types are of a vendor. A number of vendors are predefined in NAV, if you need to add more do it here.

If you want to use device management as your inventory system you should register the (vital) network products you order here. A product is characterized by a product number. Examples are: J899A (HP Procurve switch 2650), WS-X6516A-GBIC (SFM-capable 16 port 1000mb GBIC for Cat6k).

The device management ordering system is leaving NAV in a later version. Do not bother registering products!

You may add OIDs yourself that in turn can be built into the cricket configuration tree and thus be used as basis for gathering statistics. You need to understand the snmpoid database table to be able to enter valid input her, more info will be supplied later.

You may define subcategories within the predefines categories in NAV, see CategoriesAndTypes for more. IP devices may in turn belong to one or more subcategories.

Prefixes that are in operation are autodiscovered in NAV. The collection system finds all directly connected subnets and static routes from the routers (GW / GSW). The prefixes you can register here are of the following two types:

• scope: A scope defines your entire IP address space, i.e. 129.241.0.0/16. You may define more than one scope. Each scope can in turn be seen in the IP address scope - graphical view under the report tool.
• reserved: A reserved prefix is not in operation, but allocated for a certain purpose. Reserved scopes will be visable in the IP address scope - graphical view and the prefix report. When the prefix later is found in operation, the collection system will automatically change the network type to an operational type.

A vlan is equivalent to a broadcast domain which in turn may consist of zero, one of more IP subnets (usually one). All vlans are autodiscovered in NAV. If the NAV guidelines for configuring router interface descriptions are followed, the collection system has an easy task filling in information on network type, organization and usage. The vlan value can also in many (most) cases be automatically derived. If the guidelines are not followed the network type will be automatically derived (correctly in most cases). If the UNINETT description guidelines are followed, the collection system will set the middle part (logical portname) as netident.

In any circumstance, if there are missing or false information in the vlan table, you can manually adjust/complete the information. Note that the collection system may override your changes in some cases.

If you like, you can document your cabling system. For each room (wiring closet) register the jack numbers and the target building and room number. Also regisgter the twisted pair category and a description if you like.

Similarly you can register patches that are done in the wiring closets from switch port to jack. The patch may be a split, register what kind, and what leaf.

By maintaining data on cabling and patch the machine tracker is able to track a given machine all the way to an office (room number). Note that this is not implemented in the machine tracker tool at the time of writing, but it will be added soon (not much work).