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 using the Seed Database tool. This document explains the requirements that need to be followed in order to get NAV going.

We explain three levels of seeding data into NAV:

1. Level 1: Minimum requirements
2. Level 2: Organize your network equipment in rooms
3. Level 3: Take full advantage of NAV's capabilities

You may start on level 1 or 2, stay there forever, or later extend to level 3, as you are getting more familiar with NAV.

In all cases you may seed data in two different ways:

• The add/edit form
• The bulk import option (only for initial registration of a new entity)

The latter allows you to gather all your data in colon separated text files and easily import all these seed data into NAV. You may have other sources of this seed data and can consider extracting the data from these sources and automatically build your seed text files.

Please note that after you have bulk imported a given entity and later would like to change some of the entity attributes, this must be done with the edit form (we do not support bulk sync, only initial import).

When you seed network equipment into NAV you need to specify the organization that is operationally responsible for the equipment, and further the room the equipment is placed in. A room needs further to belong to a location. To make things simple a fresh NAV install includes the organization myorg, the room myroom and the location mylocation. You may register all your equipment belonging to myorg and placed in myroom.

The minimum requirements are:

• Register all equipment you want NAV to monitor with:
  • IP address (for routers it is best to register the loopback address)
  • room: use myroom
  • organization: use myorg
  • category: NAV has 7 predefined categories. They are: GW, GSW, SW, WLAN, EDGE, SRV and OTHER. More details here.
  • SNMP read community: Required if your device is of category GW, GSW, SW, WLAN or EDGE
  • SNMP write community: If you plan to use the port blocker, Arnold, or use the configure ports option (PortAdmin) of IP Device Info, SNMP write communities are also required for your switches.

If you stick with these minimum requirements it will mean NAV has no information of where the equipment is located, nor what organizations are involved. Further, since you have not yet adopted the recommended NAV guidelines for configuring router interface description, you will have no information on the ownership and usage of the various subnets/vlans. It is of course possible to improve these things at a later stage when you are ready to get better organized.

You may of course use bulk import with the minimum requirements to be even more efficient. You only need to bulk the IP devices. An example follows:

#roomid:ip:orgid:catid[:ro:serial:rw:function:subcat:...]
myroom:10.0.0.101:myorg:GW:public
myroom:10.10.10.11:myorg:SW:public::private
myroom:10.10.20.100:myorg:SRV
myroom:10.10.10.12:myorg:SW:public::private
myroom:10.10.10.13:myorg:SW:public::private
myroom:10.10.10.14:myorg:SW:public::private

Level 2 extends the minimum requirements to:

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, i.e. use a location per campus).
3. Define the organizational entities that are responsible for your IP devices (may be only one organization; IT department)
4. Register your IP devices you want managed by NAV.

To make things most efficient Seed Database has the ability to bulk import data from text files using a colon separated list.

In our example we have a campus network spread across three campuses around town. We have 7 rooms were the network/server equipment is placed. We have included 6 IP devices in the example.

Do to the given dependencies you should do your bulk import in the same order as in our example:

Your location bulk text file will be:

#locationid:descr
campusA:campus at the east side of town
campusB:campus at the west side of town
campusC:campus at the north side of town

You room bulk text file will be (you may skip the description, it is not compulsory):

#roomid:locationid:[descr:opt1:opt2:opt3:opt4:position]
room1:campusA:Room C302 in Math building
room2:campusA:Room B103 in Science building
room3:campusA:Room B403 in Science building
room4:campusB:Room A225 in Social sciences building
room5:campusB:Room E103 in Philosophy building
room6:campusB:Room H205 in Philosophy building
room7:campusC:Room B238 in Arts building

You could extend your room info with more data using opt1-4 and/or you could add a location coordinate (use NAV's Geomap to find, click and cut and paste your room positions). An example of the latter:

#roomid:locationid:[descr:opt1:opt2:opt3:opt4:position]
room1:campusA:Room C302 in Math building:::::63.41609, 10.4059
room2:campusA:Room B103 in Science building:::::63.41744, 10.4053
room3:campusA:Room B403 in Science building:::::63.41836, 10.4015
room4:campusB:Room A225 in Social sciences building:::::63.40718, 10.4694
room5:campusB:Room E103 in Philosophy building:::::63.40914, 10.4699
room6:campusB:Room H205 in Philosophy building:::::63.40952, 10.4730
room7:campusC:Room B238 in Arts building:::::63.42412, 10.4346

Remember that if you later would like to add more data in a room, this must be done using the edit form (you cannot bulk import the same room twice).

In our case the IT department is the owner of all equipment and we do not bother about using NAV's recommended guidelines for router interface descriptions at this level (meaning we have no way of knowing who are the users of a given subnet). The simple bulk import will be (you may even skip the description, it is not compulsory) :

#orgid[:parent:description:opt1:opt2:opt3]
IT::IT department

Now we have prepared for the juice. About time to add the equipment we want NAV to monitor.

#roomid:ip:orgid:catid[:ro:serial:rw:function:subcat:...]
room1:10.0.0.101:IT:GW:public
room1:10.10.10.11:IT:SW:public::private
room1:10.10.20.100:IT:SRV
room2:10.10.10.12:IT:SW:public::private
room2:10.10.10.13:IT:SW:public::private
room5:10.10.10.14:IT:SW:public::private

You will notice that servers have no SNMP community. The router has read community only and the switches also have WRITE community. The latter is because you want to use the port blocker tool Arnold and/or the PortAdmin tool for configuring switch ports.

To take full advantage of NAV's capabilities do the following:

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 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. Organizations
4. User categories
5. IP devices
6. Services

Registering IP devices is by far the most important and most comprehensive 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 an actual SNMP poll of the equipment is done. If it does not answer to the given SNMP read 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 (bulk import is a way of avoiding this requirement).
• SNMP write community may be registered with the device, it is not an requirement and is only needed if you are planning to use Arnold or the PortAdmin functionality available from IP Device Info. If you supply an SNMP write community NAV requires that this is a valid write community.
• 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 (we plan for NAV 3.11 of Dec 2011 to also use the system.sysname).
• 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 History 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. The subcategory will only appear as an option if there are registered subcategories for the category.

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

Data collection will commence within 2 minutes. Information on modules, switch ports and ARP data will be available shortly after this. Bridge table data and topology information will need some more time:

• The mactrace process (cam logger) 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 you bulk import IP devices you will be presented with a list of green, yellow and red lights. If you submit, IP devices 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 syntax in your file is incorrect
  • You are trying to add duplicates
• Note that when bulk importing NAV will accept IP devices even if the provided SNMP read or write communities are incorrect (NAV does not verify this in the case of bulk imports). The effect of wrong communities will of course be that no information can be read/written with SNMP. The SNMP collecter of NAV, ipDevPoll, will log this as error messages. You will also notice the the “Last updated” field in IP Device Info is not updated.
• If you are trying to import a nested organizational structure, it may be necessary to import the organization file several times.

See the Level 2 part of this document for examples of bulk imports.

We here comment on the other seed topics.

IP devices (typically servers) may have one or more services that you would like to monitor. Available services are shown in the service list when you add a service. Most services 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.

(more doc of the services options will come later)

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.
• You may also register a geographical position (register two comma separated real numbers: latitude, longitude). The Geomap tool of NAV uses the position info to show a geographical layout of your network topology. Please note that the Geomap tool can be used to locate the position on your rooms. Zoom in, locate and click on the position of your room and the last clicked position is displayed. This you can cut and paste into Seed Database|Room.
• The parameters optional1 - optional4 are generic, the idea being that they can serve a local purpose. They may describe exact room number, telephone number, 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 NAV 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. The PortAdmin tool uses this to restrict the vlans a user may alter when configuring switch ports (this has only effect if you have followed the the NAV guidelines for router interface descriptions).

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 will relate this to a known type. If the type is unknown to NAV a new type record will automatically be created. You will most probably want to edit the type name and type description manually later to get better human understandable data. This will become apparent when you look at the “all ip devices report” in the report tool.

• The sysobjectid uniquely identifies the type
• A type has a name and description
• A type belongs to a vendor
• The other fields will are:
  • 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.
  • cs at vlan should be checked if the switch is from Cisco
  • chassis should be checked it is a chassis based switch

Please note that NAV 3.10 (Aug 2011) will remove the attributes cdp, tftp, cs at vlan and chassis, and thus simply the type table a lot.

Consult the type page for more information about types.

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

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 (the latter will be included i NAV 3.11) 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. You may also define IPv6 scopes. 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 information in the vlan table, you can manually alter the information. The information you may alter are: organization, usage and vlan.

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 register the twisted pair category and a description if you like.

Please note that the cabling information is not used elsewhere in NAV, not even in the report system. It is not recommended to add data here.

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.

Please note that the patch information is not used elsewhere in NAV, not even in the report or machine tracker tools. It is not recommended to add data here.

We recommend that you instead document directly in your switch port descriptions on your switches. Document i.e. to which jack the given switch port is connected. Since switch port descriptions are collected by NAV, you can in turn easily search for a given jack using the report tool.

You will notice that it is not possible to edit the room, location or organization values directly when in edit mode. You may however obtain the same effect using the 'Move selected' option available from the 'List' tab!

From the IP device list you may:

1. select one or more IP devices (as many as you like)
2. click move selected
3. then choose whether you want to move the selected to a new room and/or a new organization
4. select the destination room/organization
5. confirm
6. Your equipment is moved!

The same operation can be done for:

• moving one/more room(s) to another location
• giving an organization a new parent organization