User Tools

Site Tools


devel:blueprints:consolidated-interface-table

Rationale

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:

-- New consolidated interface table
-- See MIB-II, IF-MIB, RFC 1229
CREATE TABLE interface (
  interfaceid SERIAL NOT NULL,
  netboxid INT4 NOT NULL,
  moduleid INT4,
  ifindex INT4 NOT NULL,
  ifname VARCHAR,
  ifdescr VARCHAR,
  iftype INT4,
  speed DOUBLE PRECISION,
  ifphysaddress MACADDR,
  ifadminstatus INT4, -- 1=up, 2=down, 3=testing
  ifoperstatus INT4,  -- 1=up, 2=down, 3=testing, 4=unknown, 5=dormant, 6=notPresent, 7=lowerLayerDown
  iflastchange INT4,
  ifconnectorpresent BOOLEAN,
  ifpromiscuousmode BOOLEAN,
  ifalias VARCHAR,
 
  -- non IF-MIB values
  media VARCHAR,
  vlan INT4,
  trunk BOOLEAN,
  duplex CHAR(1) CHECK (duplex='f' OR duplex='h'), -- f=full, h=half
 
  to_netboxid INT4, 
  to_interfaceid INT4, 
 
  gone_since TIMESTAMP,
 
  CONSTRAINT interface_pkey PRIMARY KEY (interfaceid),
  CONSTRAINT interface_netboxid_fkey 
             FOREIGN KEY (netboxid)
             REFERENCES netbox (netboxid)
             ON UPDATE CASCADE ON DELETE CASCADE,
  CONSTRAINT interface_moduleid_fkey 
             FOREIGN KEY (moduleid)
             REFERENCES module (moduleid)
             ON UPDATE CASCADE ON DELETE SET NULL,
  CONSTRAINT interface_to_netboxid_fkey 
             FOREIGN KEY (to_netboxid) 
             REFERENCES netbox (netboxid)
             ON UPDATE CASCADE ON DELETE SET NULL,
  CONSTRAINT interface_to_interfaceid_fkey 
             FOREIGN KEY (to_interfaceid) 
             REFERENCES interface (interfaceid)
             ON UPDATE CASCADE ON DELETE SET NULL,
  CONSTRAINT interface_interfaceid_netboxid_unique
             UNIQUE (interfaceid, netboxid)
);

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:

-- 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)
);
devel/blueprints/consolidated-interface-table.txt · Last modified: 2009/03/19 14:26 by morten