Differences

This shows you the differences between two versions of the page.

--- devel:database [2007/11/01 15:45]
faltin
+++ devel:database [2012/05/07 11:22] (current)
morten fix url
@@ Line 53: / Line 53: @@
 ==== netbox ====
-The netbox table is the hart of the hart so to speak, the most central table of them all.
+The netbox table is the heart of the heart 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.
@@ Line 61: / Line 61: @@
 ip              IP address of the netbox
 roomid          room the box is placed in
+deviceid        the device this is (foreign key to device)
 typeid          sysobjectid of the box
 sysname         name of the box, based on fully qualified dns name with fall back to IP address.
@@ Line 75: / Line 76: @@
 upsince         the timestamp when the box was last booted. Data is taken from mibII system.uptime
 uptodate        whether gDD has done OID classification
+discovered      timestamp when the box was first discovered by NAV
 </code>
@@ Line 100: / Line 102: @@
 <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
+auto            whether this device is discovered automatically by ipdevpoll or not
 discovered      when the device was first discovered by NAV.
 active          whether the device should be in operation (not just ordered)
-deviceorderid   the order (if any) the device is part of
 </code>
@@ Line 126: / Line 126: @@
 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
+name            Modules aren't necessarily identified using integers (as in module.module), so we add names in v3.6
 </code>
@@ Line 175: / Line 176: @@
 parent          parent organization, if any
 descr           further description
+contact         contact info
 opt1            additional info
 opt2            "
@@ Line 228: / Line 230: @@
 tftp            whether the type supports tftp storage
 </code>
+==== vendor ====
+The vendor table defines vendors. A type is of a vendor.
+<code>
+vendorid        table identifier, also the name of the vendor.
+</code>
 ===== The OID database =====
 This [[http://domen.uninett.no/~faltin/nav/navdb/netbox_related.png|diagram]] shows OID database (and more).
+The role of the OID database has changed with NAV 3.6. ipdevpoll (that replaces getDeviceData) does not depend
+on the OID database. Cricket still does and getBoksMacs still uses the oid database to figure out device
+capabilities.
 ==== snmpoid ====
@@ Line 310: / Line 325: @@
 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
+                 which table; service / interface
-value            i.e. which serviceid / swportid / gwportid
+value            i.e. which serviceid / interfaceid
 </code>
@@ Line 323: / Line 338: @@
 rrd_fileid       the rrd file the data source is within
 name             name of the source (ds0,ds1,RESPONSE TIME etc)
-descr            further description
+descr            type of datasource, i.e. ifInOctets, ifInErrors, cpu5min, etc
 dstype           type (DERIVE / GAUGE)
 units            units used on y-axis (seconds, bytes, etc)
@@ Line 336: / Line 351: @@
 </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 ====
+===== Router related topology tables =====
-The product table is used be Device Management to register products.
+Diagram 2 shows the relations between the topology related tables:
-Not compulsory.  A product has a product number and is of a vendor.
-<code>
+{{devel:db:topology.png?600|}}
-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 ====
+==== interface ====
-The devicerorder table is used by Device Management to place orders.
+New table in v3.6. General interface table, combines the old gwport and swport in one.
-Not compulsary. An order consists of a set of devices (on or more)
+In cases where attribute starts with if* it is the exact equivalent of the IF-MIB (RFC 1229) instance.
-of a certain product.
+<code>
+interfaceid        primary key
+netboxid           netbox the interface belongs to
+moduleid           module the interace is on (if found)
+ifindex            ifindex of the router port
+ifname             interface name
+ifdescr            interface
+iftype
+speed
+ifphysaddress
+ifadminstatus
+ifoperstatus
+iflastchange
+ifconnectorpresent
+ifpromiscuousmode
+ifalias
+baseport           port number (integer) if appliqable ???
+media
+vlan
+trunk
+duplex
+to_netboxid        the netbox the interface connects to (if any)
+to_interfaceid     the interface this interface connects to (if any)
-<code>
-deviceorderid   primary key
-registered      time stamp when the order is registered in NAV
-ordered         date the order is made in NAV.
-arrived         time stamp when the order has arrived
-username        NAV user placing 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 device order, but if the amount
-i.e. is 5, then 5 device order events are posted on the eventq (I think...).
 </code>
-==== vendor ====
+==== rproto_attr ====
+New table in v3.6. General table for routing protocol metrics. Relates to intervace table.
-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.
+id            primary key
+interfaceid   which interface this is (foreign key)
+protoname     protocol name, i.e. ospf, isis, etc
+metric        metric value
 </code>
-===== Router related topology tables =====
-Diagram 2 shows the relations between the topology related tables:
-{{devel:db:topology.png?600|}}
 ==== gwport ====
@@ Line 422: / Line 432: @@
 <code>
-gwportid        router port in question
+interfaceid     interface (router port) in question
 prefixid        prefix in question
 gwip            ip address defines on the router port
@@ Line 439: / Line 449: @@
 vlanid          broadcast / vlan the prefix is running on
 </code>
 ==== vlan ====
@@ Line 451: / Line 462: @@
 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
+usageid         usage of the vlan, reference to the usage table
 netident        a substring of the router port description derived
                 acccording to the suggested NAV syntax.
@@ Line 470: / Line 481: @@
                 added manually in the Edit Database tool. For these netttypes (reserved and scope) edit='t'.
 </code>
 ==== usage ====
@@ Line 478: / Line 490: @@
 <code>
 usageid         primary key, also usage value
-descr           firther description
+descr           further description
 </code>
@@ Line 502: / Line 514: @@
 This [[http://domen.uninett.no/~faltin/nav/navdb/topology.png|diagram]] showns the relations between the
 topology related tables.
 ==== swport ====
@@ Line 520: / Line 533: @@
                 also in the swportvlan table - in report it
                 is taken from swport vlan, not from here.
-trunk           wheater the port is trunk (boolean)
+trunk           whether the port is trunk (boolean).
+                May be NULL if it cannot be determined.
 portname        the configured port name (description/ifAlias value)
 to_netboxid     the netbox the port connects to (if any)
@@ Line 533: / Line 547: @@
 <code>
 swportvlanid    table primary key
-swportid        switch port id (foreign key ref to swport table)
+interfaceid     interface id (foreign key ref to interface table, i.e. which switch port is this)
 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' = ???
+                'o' = 'Up', 'n' = 'Down', 'b' = 'Blocked', 'x' = Unknown
 </code>
 ==== swportallowedvlan ====
-Stores a hexstring that has "hidden" information about the vlans that are
+Stores a string of hexadecimal digits that represents the set of VLANs that are allowed to traverse a given trunk port.  The hexadecimal string can be converted to an octet string, representing a string of bits, or a very large number, if you will:
-allowed to traverse a given trunk.
-To make this information more readable a
+  * If the hexadecimal string is 256 digits long, the most significant bit in the octet string represents VLAN 0, while the least significant bit represents VLAN 1023.  A set bit indicates that a VLAN is allowed, an unset bit indicates that it is not allowed.
-help table (range) and two views (allowedvlan and allowedvlan_both) are added to NAV
+  * If the hexadecimal string is less than 256 characters long, the bit order is reversed, and the least significant bit represents VLAN 0.
-in version 3.1. They are not documented in any further detail for the time being.
+The octet string representation is taken directly from a couple of CISCO MIBs, and as many will configure their trunks to allow any VLAN 1-1023, this representation will save space by reducing the number of necessary table rows.
+To make interpretation of this data simpler using pure SQL, a help table (//range//) and two views (//allowedvlan// and //allowedvlan_both//) are provided.  The //allowedvlan// view will decompose the hexstring into a set of VLAN rows for each trunk port.
 <code>
-swportid        switch trunk port in question
+interfaceid     switch trunk port in question (foreign key to the interface table)
-hextring        hextring that defines the allowed vlans for the trunk
+hexstring       hexstring that defines the allowed vlans for the trunk
 </code>
@@ Line 558: / Line 574: @@
 <code>
-swportid        switch port in question
+interfaceid     switch port in question (foreign key to interface table)
 vlan            vlan value
 </code>
@@ Line 573: / Line 589: @@
 ifindex         ifindex on the switch
 to_netboxid     candidate next hop netbox
-to_swportid     candidate next hop switch port
+to_interfaceid  candidate next hop switch port (foreign key to interface table)
 misscnt         see misscnt in the cam table below. Same thing.
 </code>
@@ Line 635: / Line 651: @@
 <code>
 patchid         primary key
-swportid        reference to the swport the cross connect is connected to
+interfaceid     reference to the swport the cross connect is connected to (foreign key to interface table)
 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.
@@ Line 653: / Line 669: @@
 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.
+queue and process it (getDeviceData was in some cases the target, not anymore).
 <code>
@@ Line 695: / Line 711: @@
 descr           further descr of the subsystem (not used)
 </code>
 ==== eventqvar ====
@@ Line 741: / Line 758: @@
 </code>
-==== alertmsg ====
+==== alertqmsg ====
 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.
+each configured language. The data are stored in the alertqmsg table.
 <code>
@@ Line 811: / Line 828: @@
 </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 =====
@@ Line 910: / Line 921: @@
-===== 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>
@@ Line 998: / Line 963: @@
 ==== identity ====
+:!: Not up to date!
 <code>
@@ Line 1004: / Line 971: @@
 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.
+swportid              reference to the switch port found in the interface table.
                       We find sysname,ip,module and port from this
 swsysname             current sysname of switch, kept for consistency check
@@ Line 1075: / Line 1042: @@
 version...).
-See [[http://metanav.uninett.no/static/reports/NAVMore.pdf|NAVMore report ch 2.4]] (in Norwegian) for a further explaination of
+See [[http://nav.uninett.no/static/reports/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. For an explanation of the front-end tool, see [[..sysloganalyzer|here]].

NAV Wiki

User Tools

Site Tools

Differences

Page Tools