seedessentials
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
seedessentials [2011/04/03 15:04] – faltin | seedessentials [2014/03/27 10:31] (current) – morten | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Seed the NAV database with the Seed Database tool ====== | + | Most of the information on this page has been moved to NAV' |
- | + | ||
- | {{tools: | + | |
- | + | ||
- | We explain three levels | + | |
- | - Level 1: Minimum requirements | + | |
- | - Level 2: Organize your network equipment in rooms, use bulk import | + | |
- | - Level 3: Take fully 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. | + | |
- | + | ||
- | ====== Level 1: Minimum requirements ====== | + | |
- | + | ||
- | When you seed network equipement into NAV you need to specify | + | |
- | + | ||
- | The mimimum 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 '' | + | |
- | * organization: | + | |
- | * category: NAV has 7 predefined categories. They are: GW, GSW, SW, WLAN, EDGE, SRV and OTHER. [[CategoriesAndTypes|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|Arnold]], | + | |
- | + | ||
- | + | ||
- | 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 [[subnetsandvlans# | + | |
- | + | ||
- | 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: | + | |
- | + | ||
- | < | + | |
- | # | + | |
- | my_room: | + | |
- | my_room: | + | |
- | my_room: | + | |
- | my_room: | + | |
- | my_room: | + | |
- | my_room: | + | |
- | </ | + | |
- | + | ||
- | ====== Level 2: Organize your network equipment in rooms, use bulk import ====== | + | |
- | + | ||
- | Level 2 extends the minimum requirements to: | + | |
- | + | ||
- | - Define all physical location where equipment is placed, i.e. network/ | + | |
- | - Organize rooms in locations (locations serve as natural geographical domains, i.e. use a location per campus). | + | |
- | - Define the organizational entities that are responsible for your IP devices (may be only one organization; | + | |
- | - Register your IP devices you want managed by NAV. | + | |
- | + | ||
- | ===== Bulk import example ===== | + | |
- | + | ||
- | :!: To make things most efficient Seed Database | + | |
- | + | ||
- | In our example we have a campus network spread across three campuses around town. We have 7 rooms were the network/ | + | |
- | 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: | + | |
- | ==== Bulk locations ==== | + | |
- | + | ||
- | Your location bulk text file will be: | + | |
- | + | ||
- | < | + | |
- | # | + | |
- | campusA: | + | |
- | campusB: | + | |
- | campusC: | + | |
- | </ | + | |
- | + | ||
- | ==== Bulk rooms ==== | + | |
- | + | ||
- | You room bulk text file will be (you may skip the description, | + | |
- | + | ||
- | < | + | |
- | # | + | |
- | room1: | + | |
- | room2: | + | |
- | room3: | + | |
- | room4: | + | |
- | room5: | + | |
- | room6: | + | |
- | room7: | + | |
- | </ | + | |
- | + | ||
- | You could extend your room info with more data using opt1-4 and/or you could add a location coordinate (use NAV' | + | |
- | + | ||
- | < | + | |
- | # | + | |
- | room1: | + | |
- | room2: | + | |
- | room3: | + | |
- | room4: | + | |
- | room5: | + | |
- | room6: | + | |
- | room7: | + | |
- | </ | + | |
- | + | ||
- | ==== Bulk organizations ==== | + | |
- | + | ||
- | 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, | + | |
- | + | ||
- | < | + | |
- | #orgid[:parent: | + | |
- | IT::IT department | + | |
- | </code> | + | |
- | + | ||
- | ==== Bulk IP devices ==== | + | |
- | + | ||
- | Now we have prepared for the juice. About time to add the equipment we want NAV to monitor. | + | |
- | + | ||
- | < | + | |
- | # | + | |
- | room1: | + | |
- | room1: | + | |
- | room1: | + | |
- | room2: | + | |
- | room2: | + | |
- | room5: | + | |
- | </ | + | |
- | + | ||
- | 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. | + | |
- | + | ||
- | ====== Level 3: Take fully advantage of NAV's capabilities ====== | + | |
- | - Define all physical location where equipment is placed, i.e. network/server rooms and wiring closets. | + | |
- | - Organize rooms in locations (locations serve as natural geographical domains). | + | |
- | - 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. | + | |
- | - Define the natural usage categories for your subnets (students, staff, administration etc). | + | |
- | - Adopt the [[subnetsandvlans# | + | |
- | - Fill in your IP address scope(s) by using "add prefix" | + | |
- | - Register your IP devices you want managed by NAV. See [[# | + | |
- | + | ||
- | + | ||
- | ====== The order of things ====== | + | |
- | Due to dependencies within the database, it is recommended that you register seed data in the following order: | + | |
- | + | ||
- | - Locations | + | |
- | - Rooms | + | |
- | - Organizations | + | |
- | - User categories | + | |
- | - IP devices | + | |
- | - Services | + | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | ====== Registering a new IP device ====== | + | |
- | 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 (or after your bulk submit) 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|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 | + | |
- | * NAV will also derive the serial number from the equipment. If this fails, or if you for some reason | + | |
- | * 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 [[backendprocesses# | + | |
- | * [[backendprocesses# | + | |
- | + | ||
- | + | ||
- | + | ||
- | ====== Bulk import ====== | + | |
- | 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. 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 can also notice the the "Last updated" | + | |
- | * 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. | + | |
- | + | ||
- | + | ||
- | ===== Services ===== | + | |
- | IP devices (typically servers) may have one or more services that you would like to monitor. Available sewrvices are shown in the service list when you add a service. Some services requires extra arguments, they may also have optional arguments. I.e. for imap you have to supply a username/ | + | |
- | + | ||
- | + | ||
- | + | ||
- | ===== Rooms ===== | + | |
- | 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 | + | |
- | + | ||
- | ===== Location ===== | + | |
- | A location is a geographical area containing a number of rooms. The locationid is max 30 characters. | + | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | ===== Organization ===== | + | |
- | An organization has a name of max 30 characters. It may have a parent organization, | + | |
- | 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 [[reporttool# | + | |
- | You may for instance want to register an email address or a contact person etc. | + | |
- | + | ||
- | Note that organization in NAV serves three purposes: | + | |
- | + | ||
- | - Each subnet typically hosts an organization (i.e. a physics department subnet). NAV can interpret this if you follow [[subnetsandvlans# | + | |
- | - Each IP device has an organization that are in charge of operation (registered when adding the IP device). | + | |
- | - 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 [[subnetsandvlans# | + | |
- | ===== Usage categories ===== | + | |
- | 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. | + | |
- | + | ||
- | + | ||
- | + | ||
- | ===== Type ===== | + | |
- | All equipment that answers to SNMP supply a system.sysObjectID, | + | |
- | + | ||
- | * 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 [[EquipmentTypes|type page]] for more information about types. | + | |
- | + | ||
- | ===== Vendor ===== | + | |
- | Types are of a vendor. A number of vendors are predefined in NAV, if you need to add more do it here. | + | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | ===== Subcategory ===== | + | |
- | 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. | + | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | ===== Prefix | + | |
- | 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/ | + | |
- | * reserved: A reserved prefix is not in operation, but allocated for a certain purpose. Reserved scopes will be visable in [[reporttool# | + | |
- | + | ||
- | + | ||
- | + | ||
- | ===== Vlan ===== | + | |
- | 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 [[subnetsandvlans# | + | |
- | + | ||
- | :!: In any circumstance, | + | |
- | ===== Cabling ===== | + | |
- | 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. | + | |
- | + | ||
- | ===== Patch ===== | + | |
- | 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. | + | |
- | + | ||
- | + | ||
seedessentials.1301843063.txt.gz · Last modified: by faltin