devel:blueprints:consolidated-interface-table
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
devel:blueprints:consolidated-interface-table [2009/02/06 10:53] morten created |
devel:blueprints:consolidated-interface-table [2009/03/19 13:26] (current) morten |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | A preliminary schema for a new table: | + | ====== Rationale ====== |
| - | <code sql> | + | NAV has for many years had an artifical divide between switch ports and router interfaces, which are stored in each their table (//swport// and //gwport//). |
| + | Conceptually, they are all just network interfaces, which share a set of attributes. On routers, interfaces can also operate on the IP layer, which adds some attributes. | ||
| + | NAV contains a lot of duplicate and/or complex code to work with both swports and gwports, since they are in separate tables. Also, many data structures and lookups are complicated by the fact that the current model requires an swport/gwport to be related to a module, not to a netbox. In reality, interfaces are uniquely adressed within a single SNMP agent, and we cannot always determine which module an interface is physically attached to. For devices that don't really have modules, NAV will currently create a pseudo-module related to the same device (serial number) as the netbox, just so it can add ports to the netbox. We aim to make an interface's relationship to a module an optional bonus, and thus make many joins with the module table superfluous. | ||
| + | |||
| + | |||
| + | ====== New schema ====== | ||
| + | A preliminary schema for a new interface table: | ||
| + | <code sql> | ||
| -- New consolidated interface table | -- New consolidated interface table | ||
| -- See MIB-II, IF-MIB, RFC 1229 | -- See MIB-II, IF-MIB, RFC 1229 | ||
| CREATE TABLE interface ( | CREATE TABLE interface ( | ||
| - | interfaceid SERIAL, | + | interfaceid SERIAL NOT NULL, |
| - | netboxid INT4, | + | netboxid INT4 NOT NULL, |
| moduleid INT4, | moduleid INT4, | ||
| ifindex INT4 NOT NULL, | ifindex INT4 NOT NULL, | ||
| Line 14: | Line 21: | ||
| speed DOUBLE PRECISION, | speed DOUBLE PRECISION, | ||
| ifphysaddress MACADDR, | ifphysaddress MACADDR, | ||
| - | ifadminstatus INT4, | + | ifadminstatus INT4, -- 1=up, 2=down, 3=testing |
| - | ifoperstatus INT4, | + | ifoperstatus INT4, -- 1=up, 2=down, 3=testing, 4=unknown, 5=dormant, 6=notPresent, 7=lowerLayerDown |
| iflastchange INT4, | iflastchange INT4, | ||
| ifconnectorpresent BOOLEAN, | ifconnectorpresent BOOLEAN, | ||
| Line 30: | Line 37: | ||
| to_interfaceid INT4, | to_interfaceid INT4, | ||
| + | gone_since TIMESTAMP, | ||
| | | ||
| CONSTRAINT interface_pkey PRIMARY KEY (interfaceid), | CONSTRAINT interface_pkey PRIMARY KEY (interfaceid), | ||
| Line 51: | Line 59: | ||
| UNIQUE (interfaceid, netboxid) | UNIQUE (interfaceid, netboxid) | ||
| ); | ); | ||
| + | |||
| </code> | </code> | ||
| + | |||
| + | The gwport table contains a field dubbed ''metric'', which represents OSPF metric, where applicable. A router interface may in reality use multiple routing protocols, so this piece of information should be in an ancillary table: | ||
| + | |||
| + | <code sql> | ||
| + | -- Routing protocol attributes | ||
| + | CREATE TABLE rproto_attr ( | ||
| + | id SERIAL NOT NULL, | ||
| + | interfaceid INT4 NOT NULL, | ||
| + | protoname VARCHAR NOT NULL, -- bgp/ospf/isis | ||
| + | metric INT4, | ||
| + | |||
| + | CONSTRAINT rproto_attr_pkey | ||
| + | PRIMARY KEY (id), | ||
| + | CONSTRAINT rproto_attr_interfaceid_fkey | ||
| + | FOREIGN KEY (interfaceid) | ||
| + | REFERENCES interface (interfaceid) | ||
| + | ); | ||
| + | </code> | ||
| + | |||
devel/blueprints/consolidated-interface-table.1233917623.txt.gz · Last modified: 2009/02/06 10:53 by morten
Page Tools
