This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | |||
databasedoc [2007/05/11 14:39] jodal Moved to devel. |
— (current) | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | |||
- | [[TableOfContents]] | ||
- | |||
- | ====== Introduction ====== | ||
- | |||
- | This documents gives detailed information on the design of the NAV database. Currently (version 3.1) NAV | ||
- | is split into four separate databases, with a total of **94 tables**: | ||
- | |||
- | * The main database "manage" is also refered to as NAVdb and contains the topology information of the network, | ||
- | machine tracker data, tables for the event- and alert system, for the messages system and more. | ||
- | The "manage" database has 57 tables. | ||
- | |||
- | * The "NAV profiles" database has information on NAV users and their selectet alert profiles. | ||
- | The "NAV profiles" database has 27 tables. | ||
- | |||
- | * The "Arnold" database has information on switch ports that are blocked by the Arnold front end tool. The "Arnold" database has 4 tables. | ||
- | |||
- | * The "logger" database is a small database for the Cisco syslog analyzer component of NAV. The | ||
- | database has 6 tables. | ||
- | |||
- | ====== NAVdb ("manage") ====== | ||
- | |||
- | Allthough this is one big database, we have here split NAVdb in 9 different logical groups of tables. This | ||
- | is shown on 5 different diagrams: | ||
- | |||
- | * [[http://domen.uninett.no/~faltin/nav/navdb/netbox_related.png|Diagram 1]] shows these groups of tables: | ||
- | * Netbox related tables | ||
- | * The OID database | ||
- | * Tables for serviceMon | ||
- | * Tables used by Device Management | ||
- | * [[http://domen.uninett.no/~faltin/nav/navdb/topology.png|Diagram 2]] shows topology related tables: | ||
- | * Router related topology | ||
- | * Switch related topology | ||
- | * [[http://domen.uninett.no/~faltin/nav/navdb/eventDB.png|Diagram 3]] shows tables for: | ||
- | * The event and alert system | ||
- | * [[http://domen.uninett.no/~faltin/nav/navdb/message.png|Diagram 4]] shows tables for: | ||
- | * The message and maintenance system | ||
- | * [[http://domen.uninett.no/~faltin/nav/navdb/trafficmap.png|Diagram 5]] shows tables for: | ||
- | * The traffic map (vlanplot) | ||
- | |||
- | |||
- | |||
- | ===== Netbox related tables ===== | ||
- | |||
- | This [[http://domen.uninett.no/~faltin/nav/navdb/netbox_related.png|diagram]] gives shows the relations between the | ||
- | group of tables in this section. | ||
- | |||
- | ==== netbox ==== | ||
- | |||
- | The netbox table is the hart of the hart so to speak, the most central table of them all. | ||
- | The netbox tables contains information on all IP devices that NAV manages with adhering | ||
- | information and relations. | ||
- | |||
- | <code> | ||
- | netboxid primary key | ||
- | ip IP address of the netbox | ||
- | roomid room the box is placed in | ||
- | typeid sysobjectid of the box | ||
- | sysname name of the box, based on fully qualified dns name with fallback to IP address. | ||
- | Histically MibII system.sysname was used as source, but we now use dns. | ||
- | catid category of the box (GW,SW,SRV, etc) | ||
- | subcat DEPRECATED? - check before delete!!! | ||
- | orgid organization that manages the box | ||
- | ro snmp read community | ||
- | rw snmp write community | ||
- | prefixid prefix the netbox is on | ||
- | up whether the box is up and running (as seen from pping) | ||
- | snmp_version version of the snmp agent (1 or 2) | ||
- | snmp_agent DEPRECATED? - check before delet!!! Was used by a server collection module once. | ||
- | upsince the timestamp when the box was last booted. Data is taken from mibII system.uptime | ||
- | uptodate whether gDD has done OID classification | ||
- | </code> | ||
- | |||
- | ==== netboxinfo ==== | ||
- | |||
- | The netboxinfo table is the place to store additional info on a netbox. | ||
- | |||
- | <code> | ||
- | netboxinfoid primary key | ||
- | netboxid netbox the info relates to | ||
- | key not alway used, adds another dimension to (var,val). gDD uses i.e. this when storing collected | ||
- | CDP data for a netbox. | ||
- | var variable | ||
- | val value | ||
- | </code> | ||
- | |||
- | ==== device ==== | ||
- | |||
- | The device table contains all physical devices in the network. As opposed to | ||
- | the netbox table, the device table focuses on the physical box with its serial | ||
- | number. The device may appear as different net boxes or may appear in different | ||
- | modules throughout its lifetime. | ||
- | |||
- | <code> | ||
- | deviceid primary key | ||
- | productid product the device is of (if this info is maintained) | ||
- | serial serial number | ||
- | hw_ver hardware version | ||
- | fw_ver firmware version | ||
- | sw_ver software version | ||
- | auto whether this device is discovered automatically by gDD or not | ||
- | active whether the device should be in operation (not just ordered) | ||
- | deviceorderid the order (if any) the device is part of | ||
- | </code> | ||
- | |||
- | ==== module ==== | ||
- | |||
- | The module table defines modules. A module is a part of a netbox of category GW, SW and GSW. | ||
- | A module has ports; i.e router ports and/or switch ports. A module is also a phyiscal | ||
- | device with a serial number. | ||
- | |||
- | <code> | ||
- | moduleid primary key | ||
- | deviceid the device this is | ||
- | netboxid netbox the module is a part of | ||
- | module the module number (integer - may be confusing) | ||
- | model the model description (as given by the vendor) | ||
- | descr further description (as given by the vendor) | ||
- | up whether the module is up and running (as detected by moduleMon. modeleMon is a plugin to gDD) | ||
- | downsince since when the module has been down | ||
- | </code> | ||
- | |||
- | ==== mem ==== | ||
- | |||
- | The mem table describes the memory (memory and nvram) of a netbox. | ||
- | |||
- | <code> | ||
- | memid primary key | ||
- | netboxid netbox the memory is part of | ||
- | memtype type of memory (flash or memory) | ||
- | device memory device (bootflash, slot0, disk1, etc) | ||
- | size size of the memory in byte | ||
- | used how much of the memory that is used | ||
- | </code> | ||
- | |||
- | ==== room ==== | ||
- | |||
- | The room table defines a wiring closes / netork room / server room | ||
- | |||
- | <code> | ||
- | roomid primary key - text - also the name of the room | ||
- | locationid in which location the room is | ||
- | descr description of the room | ||
- | opt1 additional info | ||
- | opt2 " | ||
- | opt3 " | ||
- | opt4 " | ||
- | </code> | ||
- | |||
- | ==== location ==== | ||
- | |||
- | The location table defines a group of rooms; i.e. a campus. | ||
- | |||
- | <code> | ||
- | locationid primary key - text - also name of location | ||
- | descr further description | ||
- | </code> | ||
- | |||
- | ==== org ==== | ||
- | |||
- | The org table defines an organization. | ||
- | * An organization is in charge of a given netbox. | ||
- | * An organization is using a given prefix (to derive this relation you must adopt the NAV guidelines for router descriptions as explained in SubnetsAndVlans). | ||
- | |||
- | <code> | ||
- | orgid primary key - text - also name of org | ||
- | parent parent organization, if any | ||
- | descr further description | ||
- | opt1 additional info | ||
- | opt2 " | ||
- | opt3 " | ||
- | </code> | ||
- | |||
- | ==== cat ==== | ||
- | |||
- | The cat table defines the categories of a netbox (GW,GSW,SW,EDGE,WLAN,SRV,OTHER). | ||
- | |||
- | <code> | ||
- | catid primary key - predefined categories | ||
- | (GW,GSW,SW,EDGE,WLAN,SRV,OTHER) | ||
- | descr further description | ||
- | req_snmp whether NAV requires snmp support for the category | ||
- | (false for SRV and OTHER, true for the five others) | ||
- | </code> | ||
- | |||
- | ==== subcat ==== | ||
- | |||
- | The subcat table defines subcategories within a category. A category may have many subcategories. | ||
- | A subcategory belong to one and only one category. | ||
- | |||
- | <code> | ||
- | subcatid primary key - text - also name of subcat | ||
- | descr further description | ||
- | catid category the subcat belongs to | ||
- | </code> | ||
- | |||
- | ==== netboxcategory ==== | ||
- | |||
- | A netbox may be in many subcategories. This relation is defined here. | ||
- | |||
- | <code> | ||
- | netboxid netbox in question | ||
- | category _subcat_ in question | ||
- | </code> | ||
- | |||
- | ==== type ==== | ||
- | |||
- | The type table defines the type of a netbox, the sysobjectid being the unique identifier. | ||
- | |||
- | <code> | ||
- | typeid primary key | ||
- | vendorid vendor of this equipment type | ||
- | typename name of the type | ||
- | descr further description | ||
- | sysobjectid sysobjectid | ||
- | cs_at_vlan whether the type uses community@vlan snmp polls | ||
- | chassis whether this is a chassis type box or not | ||
- | frequency DEPRECATED - check before delete!!! | ||
- | cdp whether the type supports cdp | ||
- | tftp whether the type supports tftp storage | ||
- | </code> | ||
- | |||
- | ===== The OID database ===== | ||
- | |||
- | This [[http://domen.uninett.no/~faltin/nav/navdb/netbox_related.png|diagram]] shows OID database (and more). | ||
- | |||
- | ==== snmpoid ==== | ||
- | |||
- | The snmpoid table defines all OIDs used during snmp data gathering and/or Cricket data collection. | ||
- | |||
- | <code> | ||
- | snmpoidid primary key | ||
- | snmpoid the OID | ||
- | oidkey the variable used in NAV code for the OID | ||
- | oidsource whether Cricket uses the oid or not | ||
- | match_regex the response from the OID must mach the regex defined her, if empty any response is ok. | ||
- | getnext If true; the OID is the root of a subtree, the OID tester then does a getnext poll to verify this. | ||
- | If false; this OID is a leaf OID. | ||
- | decodehex If true; the data is in hex and shuld be decoded to ASCII before doing the match_regex | ||
- | uptodate boolean. If false netboxes are not OID tested against this OID. If you add snmpoids in | ||
- | the Edit Database tool this value will initially be false. | ||
- | defaultfreq Default gDD poll frequency for this OID. Netboxes that are classified to answer to this OID will | ||
- | inherit this value in netboxsnmpoid. Most OIDs default to 6hrs (21600), modulemon to 1 hrs (3600). | ||
- | descr further description | ||
- | oidname the official name of the oid | ||
- | mib the MIB the oid belongs to | ||
- | </code> | ||
- | |||
- | ==== netboxsnmpoid ==== | ||
- | |||
- | The netboxsnmpoid table defines which netboxes answers to which snmpoids. | ||
- | |||
- | <code> | ||
- | netboxid which netbox | ||
- | snmpoidid which OID | ||
- | frequency How often gDD polls this OID for this netbox. The value is inherited from snmpoid.deaultfreq. | ||
- | </code> | ||
- | |||
- | ===== Tables for serviceMon ===== | ||
- | |||
- | This [[http://domen.uninett.no/~faltin/nav/navdb/netbox_related.png|diagram]] shows tables for serviceMon (and more). | ||
- | |||
- | ==== service ==== | ||
- | |||
- | The service table defines the services on a netbox that serviceMon monitors. | ||
- | |||
- | <code> | ||
- | serviceid primary key | ||
- | netboxid which netbox the service for monitoring is for | ||
- | active DEPRECATED? - check before remove. Was used for maintenance. | ||
- | handler type of service (ssh,http,dns,dvc etc) | ||
- | version version of the service, i.e. apache/ssh verson | ||
- | up whether serviceMon finds that the service is up/down | ||
- | </code> | ||
- | |||
- | ==== serviceproperty ==== | ||
- | |||
- | Each service may have an additional set of attributes. They are defined here. | ||
- | |||
- | <code> | ||
- | serviceid primary key | ||
- | property additional property of the service | ||
- | value the value of the property | ||
- | </code> | ||
- | |||
- | ===== The RRD database ===== | ||
- | |||
- | This [[http://domen.uninett.no/~faltin/nav/navdb/netbox_related.png|diagram]] shows the RRD database (and more). | ||
- | |||
- | ==== rrd_file ==== | ||
- | |||
- | The rrd_file contains metainformation on all RRD files that NAV | ||
- | uses. Each RRD file has statistics for a certain netbox | ||
- | |||
- | <code> | ||
- | rrd_fileid primary key | ||
- | path filesystem path to the rrd file in question | ||
- | filename filename of the rrd file | ||
- | step how often the rrd fil is updated (in seconds) | ||
- | subsystem the subsystem that is updating the file | ||
- | (typically cricket, pping or servicemon) | ||
- | netboxid the netbox the rrd file has statistics for | ||
- | key if relevant, which part of the netbox the rrd file has statistics for, i.e. | ||
- | which table; service / swport or gwport | ||
- | value i.e. which serviceid / swportid / gwportid | ||
- | </code> | ||
- | |||
- | ==== rrd_datasource ==== | ||
- | |||
- | An rrd_file consists of a set of datasources defined in this table. | ||
- | A datasource is a data set, i.e. outOctets for a given switchport on a given switch. | ||
- | |||
- | <code> | ||
- | rrd_datasourceid primary key | ||
- | rrd_fileid the rrd file the datasource is within | ||
- | name name of the source (ds0,ds1,RESPOSETIME etc) | ||
- | descr further description | ||
- | dstype type (DERIVE / GAUGE) | ||
- | units units used on y-axis (seconds, bytes, etc) | ||
- | threshold for thresholdmon: the threshold value to be checked on this data source. | ||
- | May be stored as an integer or a percentage number. | ||
- | max for thresholdmon: the max value that this datasource may be. Important if | ||
- | the threshold is stored as percentage. | ||
- | delimiter for thresholdmon: either '<' or '>'. Tells us if the value must be higher or | ||
- | lower than the threshold. | ||
- | thresholdstate for thresholdmon: if this is set to 'active' we have sent an alert on this | ||
- | data source, if it is inactive, we have not. | ||
- | </code> | ||
- | |||
- | ===== Tables used by Device Management ===== | ||
- | |||
- | This [[http://domen.uninett.no/~faltin/nav/navdb/netbox_related.png|diagram]] shows tables for Device Management (and more). | ||
- | |||
- | ==== product ==== | ||
- | |||
- | The product table is used be Device Management to register products. | ||
- | Not compulsary. A product has a product number and is of a vendor. | ||
- | |||
- | <code> | ||
- | productid primary key | ||
- | productno product identifier, i.e. "WS-X4148-RJ" | ||
- | descr further descr, i.e. "48 ports 10/100BaseTX (RJ45)" | ||
- | vendorid Vendor of the product | ||
- | </code> | ||
- | |||
- | ==== deviceorder ==== | ||
- | |||
- | The devicerorder table is used by Device Management to place orders. | ||
- | Not compulsary. An order consists of a set of devices (on or more) | ||
- | of a certain product. | ||
- | |||
- | |||
- | <code> | ||
- | deviceorderid primary key | ||
- | registered timestamp when the order is registered in NAV | ||
- | ordered date the order is made in NAV. | ||
- | arrived timestamp when the order has arrived | ||
- | username NAV user placinrg the order | ||
- | orgid organization placing the order | ||
- | retailer retailer where the order is placed | ||
- | ordernumber ordernumber used internally or by retailer | ||
- | comment further comments made regarding the order | ||
- | productid product that is ordered | ||
- | updatedby ??? | ||
- | lastupdated ??? | ||
- | |||
- | note: the amount is not registered in deviceorder, but if the amount | ||
- | i.e. is 5, then 5 deviceorder events are posted on the eventq (I think...). | ||
- | </code> | ||
- | |||
- | ==== vendor ==== | ||
- | |||
- | The vendor table defines vendors. A type is of a vendor. | ||
- | A product is of a vendor. | ||
- | |||
- | <code> | ||
- | vendorid table identifier, also the name of the vendor. | ||
- | </code> | ||
- | |||
- | ===== Router related topology tables ===== | ||
- | |||
- | This [[http://domen.uninett.no/~faltin/nav/navdb/topology.png|diagram]] showns the relations between the | ||
- | topology related tables. | ||
- | |||
- | |||
- | ==== gwport ==== | ||
- | |||
- | The gwport table defines the router ports connected to a module. | ||
- | Only router ports that are //not// shutdown are included. | ||
- | Router ports without defined IP adresses are also excluded. | ||
- | |||
- | <code> | ||
- | gwportid primary key | ||
- | moduleid module the router port is on | ||
- | ifindex ifindex of the routerport | ||
- | link whether the router port is operState up or down, apparently not in use | ||
- | masterindex if the routerport is a subinterface, this value | ||
- | points to the gwportid of the master port. | ||
- | interface interface textual name (i.e Ethernet1/2) | ||
- | speed speed in Mbps (1000 => 1 Gbps) | ||
- | metric ospf metric defined on the router port, if relevant. | ||
- | portname router interface description (the whole string) | ||
- | to_netboxid the netbox the router port connects to (if any) | ||
- | to_swportid the swith port the router connestc to (if any) | ||
- | |||
- | |||
- | </code> | ||
- | |||
- | ==== gwportprefix ==== | ||
- | |||
- | The gwportprefix table defines the router port IP addresses, one or more. | ||
- | HSRP is also supported. | ||
- | |||
- | <code> | ||
- | gwportid router port in question | ||
- | prefixid prefix in question | ||
- | gwip ip address defines on the router port | ||
- | hsrp boolean. If true, the ip address is an hsrp address | ||
- | |||
- | Note: this allows for secondary addresses on router ports. | ||
- | </code> | ||
- | |||
- | ==== prefix ==== | ||
- | |||
- | The prefix table stores IP prefixes. | ||
- | |||
- | <code> | ||
- | prefixid primary key | ||
- | netaddr cidr prefix | ||
- | vlanid broadcast / vlan the prefix is running on | ||
- | </code> | ||
- | |||
- | ==== vlan ==== | ||
- | |||
- | The vlan table defines the IP broadcast domain / vlan. | ||
- | A broadcast domain often has a vlan value, it may consist of many IP prefixes, it | ||
- | is of a network type, it is used by an organization (org) and has a user group (usage) within the org. | ||
- | |||
- | <code> | ||
- | vlanid primary key | ||
- | vlan vlan value | ||
- | nettype nettype of the vlan, reference to the nettype table | ||
- | orgid org. of the vlan, reference to the org table | ||
- | unageid usage of the vlan, reference to the usage table | ||
- | netident a substring of the router port description derived | ||
- | acccording to the suggested NAV syntax. | ||
- | description also a substring of the router port description derived | ||
- | acccording to the suggested NAV syntax. | ||
- | </code> | ||
- | |||
- | ==== nettype ==== | ||
- | |||
- | The nettype table defines network type;lan, core, link, elink, loopback, closed, static, reserved, scope. | ||
- | For a definition se SubnetsAndVlans. The network types are predefined in NAV and may not be altered. | ||
- | |||
- | <code> | ||
- | nettypeid primary key, also nettype value; | ||
- | - lan, link core, elink, static, scope etc | ||
- | descr further description | ||
- | edit Prefixes that are reserved, but not in operation or define your outer scope may be | ||
- | added manually in the Edit Database tool. For these netttypes (reserved and scope) edit='t'. | ||
- | </code> | ||
- | |||
- | ==== usage ==== | ||
- | |||
- | The usage table defines the user group (student, staff etc). | ||
- | Usage categories are maintained in the edit database tool. | ||
- | |||
- | <code> | ||
- | usageid primary key, also usage value | ||
- | descr firther description | ||
- | </code> | ||
- | |||
- | ==== arp ==== | ||
- | |||
- | The arp table contains (ip, mac, time start, time end) | ||
- | |||
- | <code> | ||
- | arpid primary key | ||
- | netboxid router the arp entry comes from | ||
- | sysname the same router in name (in case the | ||
- | router is deleted, arp has historic data) | ||
- | prefixid prefix the arp entry belongs to | ||
- | ip ip address of the arp entry | ||
- | mac mac address of the arp entry | ||
- | start_time time the arp entry was first discovered | ||
- | end_time time the arp entry disappeared | ||
- | (typically 4 hours after the last packet sent). | ||
- | </code> | ||
- | |||
- | ===== Switch related topology tables ===== | ||
- | |||
- | This [[http://domen.uninett.no/~faltin/nav/navdb/topology.png|diagram]] showns the relations between the | ||
- | topology related tables. | ||
- | |||
- | ==== swport ==== | ||
- | |||
- | The swport table defines the switchports connected to a module. | ||
- | |||
- | <code> | ||
- | swportid primary key | ||
- | moduleid module the swith port is on | ||
- | ifindex ifindex of the swport | ||
- | port port number (integer) if appliqable | ||
- | interface interface name | ||
- | link wheather the port has link. 'd' means ??? | ||
- | speed speed of the port in Mbps (1000 => 1 Gbps) | ||
- | duplex half or full duplex (h/f) | ||
- | media media type - not collected ??? USED? | ||
- | vlan vlan value of non trunk ports. This value is | ||
- | also in the swportvlan table - in report it | ||
- | is taken from swport vlan, not from here. | ||
- | trunk wheater the port is trunk (boolean) | ||
- | portname the configured port name (description/ifAlias value) | ||
- | to_netboxid the netbox the port connects to (if any) | ||
- | to_swportid the switch port the port connects to (if any) | ||
- | </code> | ||
- | |||
- | ==== swportvlan ==== | ||
- | |||
- | The swportvlan table defines the vlan values on all switch ports. | ||
- | dot1q trunk ports typically have several rows in this table. | ||
- | |||
- | <code> | ||
- | swportvlanid table primary key | ||
- | swportid switch port id (foreign key ref to swport table) | ||
- | vlanid vlan id (foreign key ref to vlan table, not an actual vlan number) | ||
- | direction Direction of the link, seen from the root of the topology (the vlan's router). | ||
- | 'o' = 'Up', 'n' = 'Down', 'x' = ??? | ||
- | </code> | ||
- | |||
- | ==== swportallowedvlan ==== | ||
- | |||
- | Stores a hexstring that has "hidden" information about the vlans that are | ||
- | allowed to traverse a given trunk. | ||
- | |||
- | To make this information more readable a | ||
- | help table (range) and two views (allowedvlan and allowedvlan_both) are added to NAV | ||
- | in version 3.1. They are not documented in any further detail for the time being. | ||
- | |||
- | <code> | ||
- | swportid switch trunk port in question | ||
- | hextring hextring that defines the allowed vlans for the trunk | ||
- | </code> | ||
- | |||
- | ==== swportblocked ==== | ||
- | |||
- | This table defines the spanning tree blocked ports for a given vlan for a given switch port. | ||
- | |||
- | <code> | ||
- | swportid switch port in question | ||
- | vlan vlan value | ||
- | </code> | ||
- | |||
- | ==== swp_netbox ==== | ||
- | |||
- | A help table used in the process of building the physical | ||
- | topology of the network. swp_netbox defines the candidates | ||
- | for next hop physical neighborship. | ||
- | |||
- | <code> | ||
- | swp_netboxid primary key | ||
- | netboxid switch in question | ||
- | ifindex ifindex on the switch | ||
- | to_netboxid candidate next hop netbox | ||
- | to_swportid candidate next hop switch port | ||
- | misscnt see misscnt in the cam table below. Same thing. | ||
- | </code> | ||
- | |||
- | ==== netbox_vtpvlan ==== | ||
- | |||
- | A help table that contains the vtp vlan database of a switch. | ||
- | For certain cisco switches cam information is gathered | ||
- | using a community@vlan string. It is then necessary to know all | ||
- | vlans that are active on a switch. The vtp vlan table is an | ||
- | extra source of information. | ||
- | |||
- | <code> | ||
- | netboxid relation to the netbox (switch) in question | ||
- | vtpvlan vlan value from the vtp table of the switch | ||
- | </code> | ||
- | |||
- | ==== cam ==== | ||
- | |||
- | The cam table defines (swport, mac, time start, time end) | ||
- | |||
- | <code> | ||
- | camid primary key | ||
- | netboxid switch that has the cam entry | ||
- | sysname name of the same switch, in case switch is deleted, | ||
- | cam data are historic | ||
- | ifindex infindex of the switch port for the cam entry | ||
- | module module number for the cam entry | ||
- | port port number for the cam entry | ||
- | mac mac address found on the port | ||
- | start_time time the mac address was first seen | ||
- | end_time time the mac address disappeared (idle timer in | ||
- | bridge tables are typically 5 minutes) | ||
- | misscnt count how many times the cam entry has been tried updated | ||
- | and failed. We do not want to terminate these cam entries | ||
- | right away. It is configurable how many misscnt the camlogger | ||
- | should tolerate. | ||
- | </code> | ||
- | |||
- | ===== Cabling system database ===== | ||
- | |||
- | ==== cabling ==== | ||
- | |||
- | The cabling table documents the cabling from the wirering closet's jack | ||
- | number to the end user's room number. | ||
- | |||
- | <code> | ||
- | cablingid primary key | ||
- | roomid room number | ||
- | jack jack number | ||
- | building building where the cabling is done | ||
- | targetroom room the remote end of the cabling is terminated | ||
- | descr further description, if any | ||
- | category type of cabling (i.e. cat5e, cat6 ...) | ||
- | </code> | ||
- | |||
- | ==== patch ==== | ||
- | |||
- | The patch table documents the cross connect from switch port to jack. | ||
- | |||
- | <code> | ||
- | patchid primary key | ||
- | swportid reference to the swport the cross connect is connected to | ||
- | cablingid reference to the jakc the cross connect is connected to | ||
- | split If a split cable is used in the jack end, specify type and leaf. | ||
- | </code> | ||
- | |||
- | |||
- | ===== Event system ===== | ||
- | |||
- | This [[http://domen.uninett.no/~faltin/nav/navdb/eventDB.png|diagram]] showns the relations between the | ||
- | event system tables. | ||
- | |||
- | ==== eventq ==== | ||
- | |||
- | The event queue. Additional data in eventqvar. | ||
- | Different subsystem (specified in source) post events on the event queue. | ||
- | Normally event engine is the target and will take the event off the event | ||
- | queue and process it. getDeviceData are in some cases the target. | ||
- | |||
- | <code> | ||
- | eventqid primary key | ||
- | source the subsystem that has posted the event | ||
- | (reference to subsystem table) | ||
- | target the subsystem that is the target of the event | ||
- | (reference to subsystem table). | ||
- | Usually event engine, may be gDD | ||
- | deviceid the device that the event is about | ||
- | netboxid the netbox that the event is about | ||
- | subid a sub value on the netbox, may be ... | ||
- | time time the event was posted | ||
- | eventtypeid event type, reference to the eventtype table | ||
- | state state of the event; s=start, e=end, x=not stateful | ||
- | value value if applickable | ||
- | severity severity of the event | ||
- | eventtype defines eventtypes | ||
- | </code> | ||
- | |||
- | ==== eventtype ==== | ||
- | |||
- | Defines event types. | ||
- | |||
- | <code> | ||
- | eventtypeid primary key, also event type value | ||
- | (i.e boxState, serviceState, info etc) | ||
- | eventtypedesc further description of the event | ||
- | stateful boolean value; wheather the event is statefull | ||
- | |||
- | subsystem defines subsystem that post or receives events | ||
- | </code> | ||
- | |||
- | ==== subsystem ==== | ||
- | |||
- | Defines the subsystems that post or receives an event. | ||
- | |||
- | <code> | ||
- | name name of subsystem that posts (source) or | ||
- | receives (target) event on the eventq | ||
- | descr further descr of the subsystem (not used) | ||
- | </code> | ||
- | |||
- | ==== eventqvar ==== | ||
- | |||
- | Defines additional (key,value) tuples that follow events. | ||
- | |||
- | <code> | ||
- | eventqid event in question | ||
- | var variable | ||
- | val value | ||
- | </code> | ||
- | |||
- | ==== alertq ==== | ||
- | |||
- | The alert queue. Additional data in alertqvar and alertmsg. | ||
- | Event engine posts alerts on the alert queue (and in addition | ||
- | on the alerthist table). Alert engine will process the data on | ||
- | the alert queue and send alerts to users based on their alert | ||
- | profiles. When all signed up users have received the alert, alert engine | ||
- | will delete the alert from alertq (but not from alert history). | ||
- | |||
- | <code> | ||
- | alertqid primary key | ||
- | source the subsystem that has posted the event | ||
- | (reference to subsystem table) | ||
- | deviceid the device that the event is about | ||
- | netboxid the netbox that the event is about | ||
- | subid a sub value on the netbox, may be ... | ||
- | time time the event was posted | ||
- | eventtypeid event type, reference to the eventtype table | ||
- | alerttypeid alert type, reference to the eventtype table | ||
- | state state of the event; s=start, e=end, x=not stateful | ||
- | value value if applickable | ||
- | severity severity of the event | ||
- | </code> | ||
- | |||
- | ==== alerttype ==== | ||
- | |||
- | Defines the alert types. An event type may have many alert types. | ||
- | |||
- | <code> | ||
- | alerttypeid primary key | ||
- | eventtypeid event type | ||
- | alerttype alert type name | ||
- | alerttypedesc alert type description | ||
- | </code> | ||
- | |||
- | ==== alertmsg ==== | ||
- | |||
- | Event engine will, based on alertmsg.conf, preformat the alarm messages, | ||
- | one message for each configured alert channel (email, sms), one message for | ||
- | each configured language. The data are stored in the alertmsg table. | ||
- | |||
- | <code> | ||
- | alertqid primary key | ||
- | msgtype email | sms | ||
- | language language of the message | ||
- | msg the message text | ||
- | </code> | ||
- | |||
- | ==== alertqvar ==== | ||
- | |||
- | Defines additional (key,value) tuples that follow alert. | ||
- | Note: the eventqvar tuples are passed along to the alertqvar table | ||
- | so that the variables may be used in alert profiles. | ||
- | |||
- | <code> | ||
- | alertqid primary key | ||
- | var variable | ||
- | val value | ||
- | </code> | ||
- | |||
- | |||
- | ==== alerthist ==== | ||
- | |||
- | The alert history. Simular to the alert queue with one important distinction; | ||
- | alert history stores statefull events as one row, with the start and end time | ||
- | of the event. | ||
- | |||
- | <code> | ||
- | alerthistid primary key | ||
- | source the subsystem that has posted the event | ||
- | (reference to subsystem table) | ||
- | deviceid the device that the event is about | ||
- | netboxid the netbox that the event is about | ||
- | subid a sub value on the netbox, may be ... | ||
- | start_time when the event occurred. if stateful; start time | ||
- | end_time if stateful; end time | ||
- | eventtypeid event type, reference to the eventtype table | ||
- | alerttypeid alert type, reference to the eventtype table | ||
- | value value if applickable | ||
- | severity severity of the event | ||
- | </code> | ||
- | |||
- | ==== alerthistvar ==== | ||
- | |||
- | Defines additional (key,value) tuples that follow the alerthist record. | ||
- | |||
- | <code> | ||
- | alerthistid primary key | ||
- | state state of the event; s=start, e=end, x=not stateful | ||
- | var variable | ||
- | val value | ||
- | </code> | ||
- | |||
- | ==== alerthistmsg ==== | ||
- | |||
- | To have a history of the formatted messages too, they are stored in alerthistmsg. | ||
- | |||
- | <code> | ||
- | alerthistid primary key | ||
- | state state of the event; s=start, e=end, x=not stateful | ||
- | msgtype email | sms | ||
- | language language of the message | ||
- | msg the message text | ||
- | </code> | ||
- | |||
- | ==== alertengine ==== | ||
- | |||
- | Used by alert engine to keep track of processed alerts. | ||
- | |||
- | <code> | ||
- | lastalertqid value of the last alertqid that alert engine has processed. | ||
- | </code> | ||
- | |||
- | |||
- | ===== Messages and maintenance ===== | ||
- | |||
- | This [[http://domen.uninett.no/~faltin/nav/navdb/message.png|diagram]] shows the relations between the | ||
- | message and maintenance tables. | ||
- | |||
- | ==== emotd ==== | ||
- | |||
- | The table contains the messages registered in the messages tool. | ||
- | Each message has a timeframe for when it is published on the NAV main page. | ||
- | |||
- | <code> | ||
- | emotdid primary key | ||
- | author user (NAV logged in user) who posts the message | ||
- | last_changed timestamp when the message was edited the last | ||
- | time | ||
- | type type of message: error (unplanned situation), | ||
- | scheduled outage (planned), information, internal. | ||
- | title title of the message (text) | ||
- | description further description (text) | ||
- | detail details, not shown on the NAV main page (text) | ||
- | affected end users affected (text) | ||
- | downtime downtime the message impicates (text) | ||
- | publish_start start time for when the message is published | ||
- | publish_end end time for publish | ||
- | published boolean... ??? | ||
- | replaces_emotd if the message is a follow up, reference to | ||
- | the message it replaces. | ||
- | title_en DEPRECATED? | ||
- | detail_en DEPRECATED? | ||
- | affected_en DEPRECATED? | ||
- | downtime_en DEPRECATED? | ||
- | </code> | ||
- | |||
- | ==== maintenance ==== | ||
- | |||
- | Each message may have a maintenance window. This is stored here. | ||
- | A location, room, netbox or service may be set on maintenance. | ||
- | This is given by emotd_related. | ||
- | |||
- | <code> | ||
- | maintenanceid primary key | ||
- | emotdid the message the mainenance window relates to | ||
- | maint_start start of maintenance | ||
- | maint_end end of maintenance | ||
- | state takes the values 'scheduled', 'active', 'passed' | ||
- | or 'overridden'. maintengine changes this value. | ||
- | </code> | ||
- | |||
- | ==== emotd_related ==== | ||
- | |||
- | The (key,value) pairs that are on maintenance. | ||
- | |||
- | <code> | ||
- | emotdid the message the maintenance relates to | ||
- | key may be location / room / netbox or module | ||
- | value relevant locationid/roomid/netboxid/serviceid | ||
- | </code> | ||
- | |||
- | |||
- | ===== Traffic map ===== | ||
- | |||
- | |||
- | The traffic map (vlanplot) uses three tables to store values on positioning of | ||
- | routers in the graph and on the use of containers. | ||
- | This [[http://domen.uninett.no/~faltin/nav/navdb/trafficmap.png|diagram]] shows the releations between the | ||
- | traffic map tables. | ||
- | |||
- | Also, see more documentation on the TrafficMap. | ||
- | |||
- | ==== vp_netbox_xy ==== | ||
- | |||
- | The table is used for positioning nodes (routers) on the traffic map. | ||
- | A netbox may be positioned in more than one container (because we show the | ||
- | other side of the link, the netboxes themself always only belong to one container). | ||
- | |||
- | <code> | ||
- | vp_netbox_xyid primary key | ||
- | pnetboxid the netboxid of this box (router) | ||
- | x the X coordinate | ||
- | y the Y coordinate | ||
- | vp_netbox_grp_infoid reference to the container this node belongs to. | ||
- | </code> | ||
- | |||
- | ==== vp_netbox_grp_info ==== | ||
- | |||
- | The table keeps information on all containers used by the traffic map. | ||
- | Editing containers is done in Edit Database. | ||
- | |||
- | <code> | ||
- | vp_netbox_grp_infoid primary key | ||
- | name name of the container. The top container is named _Top. | ||
- | hideicons boolean. The value has different meanings, see the TrafficMap wiki page. | ||
- | iconname if a name is given and an equivalent icon is placed in the vlanPlot/icons | ||
- | directory this will be used. | ||
- | x the X coordinate of the container placement on _Top. | ||
- | y the Y coordinate of the container placement on _Top. | ||
- | </code> | ||
- | |||
- | ==== vp_netbox_grp ==== | ||
- | |||
- | The table maps netboxes to containers. This information is maintained by Edit Database. | ||
- | |||
- | <code> | ||
- | vp_netbox_grp_infoid the container | ||
- | pnetboxid the netboxid of this box (router) | ||
- | </code> | ||
- | |||
- | |||
- | |||
- | ====== The "NAV profiles database" ====== | ||
- | |||
- | The "NAV Profiles" database contains 27 tables. | ||
- | This [[http://domen.uninett.no/~faltin/nav/navdb/NAVProfiles.png|figure]] shows 21 of them. | ||
- | As the figure suggests, the "NAV Profiles" database can be subdivided into the following groups of tables: | ||
- | |||
- | * Tables managed by the **user admin** tool (yellow tables) | ||
- | * Tables managed by **alertEngine** (green tables) | ||
- | * The rest (blue and red) are used by **Alert Profiles**. | ||
- | |||
- | The last 6 tables, not included on the figure, can be grouped as follows: | ||
- | * accountorg relates users to organizations, so a part of **user admin** | ||
- | * privilege and accountgroupPrivilege relates privilege to users, administered by **user admin** | ||
- | * navbarlink and accountbarlink relates to the users setup for **nav bar preferences** | ||
- | * defaultfilter is an additional table uses by **Alert Profiles**. | ||
- | |||
- | To sum up, the 27 tables can be grouped as follows: | ||
- | |||
- | * **user admin** has 10 tables. | ||
- | * **nav bar user preference** has 2 tables. | ||
- | * **alert Engine** has 2 tables. | ||
- | * **Alert Profiles** has 13 tables. | ||
- | |||
- | We do not document the database in further detail here, but refer to | ||
- | [[http://svn.itea.ntnu.no/repos/nav/navme/branches/3.1.x/doc/sql/navprofiles.sql|navprofiles.sql]] that is | ||
- | quite well documented! | ||
- | |||
- | ====== The "Arnold" database ====== | ||
- | |||
- | The "Arnold" database contains 4 tables. | ||
- | |||
- | ==== blocked_reason ==== | ||
- | |||
- | <code> | ||
- | blocked_reasonid primary key | ||
- | text A reason for blocking a given set of switch ports | ||
- | </code> | ||
- | |||
- | ==== identity ==== | ||
- | |||
- | <code> | ||
- | identityid primary key | ||
- | mac MAC-address of computer | ||
- | blocked_status boolean | ||
- | blocked_reasonid reason of the block, reference to the blocked_reason table | ||
- | swportid reference to the switch port found in the manage.swport table. | ||
- | We find sysname,ip,module and port from this | ||
- | swsysname current sysname of switch, kept for consistency check | ||
- | swvendor vendor of switch, used to determine snmp-query | ||
- | swip current ip of switch, kept for consistency check | ||
- | swmodule current module, kept for consistency check | ||
- | swport current port, kept for consistency check | ||
- | swifindex current ifindex, kept for consistency check | ||
- | community community of switch | ||
- | ip current ip of computer | ||
- | dns current dns-name of computer | ||
- | netbios current netbios-name of computer | ||
- | starttime time of first event on this computer-swport combo | ||
- | lastchanged time of last current event on this computer-swport combo | ||
- | autoenable time for autoenable | ||
- | autoenablestep number of days to wait for autoenable | ||
- | multiple stores the amount of computers detected behind this port | ||
- | mail the mail address the warning was sent to | ||
- | secret flag this tuple as visible only to members of the secret club | ||
- | userlock lock this tuple to the specified user, it is visible but not possible to enable by other users | ||
- | orgid organization | ||
- | determined set to y if this mac/port combo is blocked with the -d option. | ||
- | </code> | ||
- | |||
- | ==== event ==== | ||
- | |||
- | <code> | ||
- | eventid primary key | ||
- | identityid reference to identity | ||
- | event_comment comment | ||
- | blocked_status boolean | ||
- | blocked_reasonid reason of block, reference to blocked_reason | ||
- | eventtime timestamp of the event | ||
- | autoenablestep ? | ||
- | username | ||
- | </code> | ||
- | |||
- | |||
- | ==== block ==== | ||
- | |||
- | The block table, in lack of a better name, is a run where we do automatic blocking | ||
- | of computers based on input ip-list. | ||
- | |||
- | <code> | ||
- | blockid primary key | ||
- | blocktitle title of block | ||
- | blockdesc description of block | ||
- | mailfile path to mailfile to use to send mail when blocking | ||
- | reasonid reason of block, reference to blocket_reason | ||
- | private if set uses the -k parameter in Arnold | ||
- | determined if set uses the -d parameter in Arnold | ||
- | incremental if set uses the -e parameter in Arnold | ||
- | blocktime days from block to autoenable | ||
- | userid the user that blocks the ip-adresses | ||
- | active if set to n will not do blocking of this kind | ||
- | lastedited timestamp of last time this block was edited | ||
- | lastedituser username of user who last edited this block | ||
- | inputfile path to file where list of ip-adresses is, if applicable | ||
- | </code> | ||
- | |||
- | |||
- | |||
- | ====== The "logger" database ====== | ||
- | |||
- | The logger database contains 6 tables. The database is used for storing Cisco syslog messages in a | ||
- | structured manner. The database has no relation to other parts of NAV, thus the logger system can be looked upon | ||
- | as a separate system (the origin table could potentially relate to the netbox table in a later | ||
- | version...). | ||
- | |||
- | See [[http://metanav.ntnu.no/NAVMore/NAVMore.pdf|NAVMore report ch 2.4]] (in Norwegian) for a further explaination of | ||
- | the NAV Cisco syslog analyzer tool. The chapter also includes a database figure, almost uptodate; the system table no longer exists and there is a newpriority reference from message to priority. | ||
- | |||
- | ==== message ==== | ||
- | |||
- | Contains the syslog messages with reference to other tables | ||
- | <code> | ||
- | id primary key | ||
- | message the message itself | ||
- | time timestamp when the message was posted | ||
- | origin reference to origin table, the box who has sent the message | ||
- | type reference to the type table, the message type, indirectly priority | ||
- | newpriority reference to priority table, used only if the priority of the message is overridden | ||
- | by rules defined in the syslog config file. | ||
- | </code> | ||
- | |||
- | ==== origin ==== | ||
- | |||
- | The box that has sent the syslog message | ||
- | <code> | ||
- | origin primary key | ||
- | name name of the box (switch,router,base station) that sent the syslog message | ||
- | category reference to category | ||
- | </code> | ||
- | |||
- | ==== category ==== | ||
- | |||
- | <code> | ||
- | category ? (gw,sw etc?) | ||
- | </code> | ||
- | |||
- | |||
- | ==== type ==== | ||
- | |||
- | <code> | ||
- | type primary key | ||
- | priority reference to priority table (value 0-7) | ||
- | facility component of the Cisco defined syslog structure (ex: IP / LINK etc) | ||
- | mnemonic component of the Cisco defined syslog structure (ex: TCP_BADCKSUM, ERROR etc) | ||
- | </code> | ||
- | |||
- | ==== priority ==== | ||
- | |||
- | Defines the eight Cisco priority levels. This table is predefined in NAV filled with | ||
- | the eight rowa of data. | ||
- | |||
- | <code> | ||
- | priority primary key, value 0-7 | ||
- | keyword name of the priority | ||
- | description explaination | ||
- | </code> | ||
- | |||
- | ==== errorerror ==== | ||
- | |||
- | Contains messages that deviate from the cisco syslog message format and thus cannot be stored in | ||
- | the given structure. | ||
- | |||
- | <code> | ||
- | id primary key | ||
- | message the message that was erroranous | ||
- | </code> | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||