This document presents a list of new features we have been working on for NAV 3.3, from February 2007 till September 2007.

Support the use of interfaces instead module/port. Module/port does not in all cases give an intuitive description of a switch port. The interface name is often better, we need to ensure (in gDD) that interface name is descriptive in all cases.

• (done 2007-07-13) Change the port field of the cam table from INT to VARCHAR, and make getBoksMacs store interface names instead of port names here.
  • Module still needs to be part of this table, as interface names can be identical across modules for virtual stacks. This can only be changed when NAV stops modeling virtual stack members as modules.

• Front end tools that are affected are:
  • (done 2007-08-15) IP device center (SMJ has been assigned this task)
  • (done 2007-07-13) machine tracker (MB has made a few cosmetic changes)
  • report
  • network map?
  • network explorer?
  • (done 2007-08-15) l2trace

• (done 2007-06-11) Make it possible to link from another tool to device history for a certain device and time frame
• (done 2007-06-11) There are bugs in device history in terms of selecting a time frame
• (done 2007-06-14) It should be easy to see events of a certain type.
• (done 2007-06-15) … i.e. see all software upgrades/changes for a router/switch - very interesting data.

In addtion to the specified tasks, the following has been done:

• Refactor subsystem from one module of 3000+ lines to 14 modules.
• Fix numerous bugs. Apparently nobody has used this subsystem much in the four years since it was conceived.

(done 2007-03-12) Improve overall performance. (Improved about 75% in r3925.)

The 'Recent alerts' table should be improved

• (wontfix) Present more relevant information in the 'Recent alerts' view
• (done 2007-06-15) Modify 'Device history' (sub tool of device management) so that it takes a netbox and to/from date as parameters
• (done 2007-06-15) Link from 'Recent alerts' to 'Device history' for the given netbox and time interval

(done 2007-07-03) Router port view

 Unfortunately we do not gather data of all router ports, only those
 in operation. This means that the router port view does not give a
 complete physical view of the box. Further we do not have data on
 duplex and trunk. In essence, the only relevant things to show is speed:
 
 Color legend: [] not active [] 10Mbps [] 100M [] 1G [] 10Gbps
 
 The port history view is not relevant for router ports either.
 
 Note: For GSW we should show both the switch port and router port view.

(wontfix) A pop up menu from the swport view that can point you to relevant links, i.e. the machines behind swport machine tracker page.

In addition, the following tasks has surfaced:

• (done 2007-07-04) Create detailed view of one gwport.
• (done 2007-07-09) Link to module view from netbox view.
• (done 2007-07-09) Show all port views in module view, not just switch port status.
• (done 2007-07-10) Show prefixes related to a gwport in the port view.

• (done 2007-07-13) Use proper tabs in the tool.

The switch search has several caveats:

• (wontfix) It does not give a proper error message if a name that is not a switch is entered. (“0 hits” is IMHO a good enough message.)
• (wontfix) Further no error is given if module or port names out of range is given. Changes here also affect the change to interface name instead of module/port. (After the switch from port numbers to interface names, 'out of range' has no meaning.)
• (done 2007-08-13) In accordance to FR 1556369 it should be possible to enter the switches ip address instead of name.

In addition:

• (done 2007-07-13) MAC search has been modified to search more effectively in the DB (mac field changed from varchar to macaddr datatype).

The following needed further clarification at a meeting, and has not been implemented in 3.3. It has been moved to a separate task, see SMJ4B for updates.

• Originally: Support search all the way to room using the cabling and patch data input from Edit DB.
  • Comment: Link historic data in the cam table with current data in the patch/cabling/room tables?!
  • Resolution: Link to the port view in IP Device Center, stating clearly that the data is reflecting the current situation. Add patch/cabling/room information to IP Device Center port view.
• Originally: The MAC search result should include port description. Perhaps link to report?
  • Comment: As it stands, the only port description available for retrieval is the current one. This will not be accurate for historical results, unless we make changes to the CAM table and the camlogger to add historical information about port descriptions.
  • Resolution: Link to the port view in IP Device Center, stating clearly that the data is reflecting the current situation.

The switch port view currently displays switch ports by number (and only displays ports that have a set port number). In line with the ongoing changes to give more prominence to interface names in the web interface, some changes need to be made:

• The switch port layout should display all entries from swport, not just those with assigned port numbers (we cannot accurately assign port numbers for all equipment).
• An abbreviated form of the interface name should be displayed in each port's box instead of the port's integer number.
  • Use the same abbreviation rules as in the newly established gwport view.
  • Sort the port boxes using a natural sort algorithm.
• The single switch port view sports a link to the machine tracker, to track the active mac addresses on a given port. Interface names are now stored in the cam data instead of port numbers, so the search URL must include the interface name instead of the port number to yield correct results.

• NAV v2 had an SNMP trap solution. We need a basic mechanism to support the reception of external snmp traps. This will supplement the mailin solution.

• Consider integration with gDD for some instances. snmp traps could in some cases trigger new data collection; i.e. a trap that reports on new mac addresses seen behind a switch port (maybe this should allow for a cam database update directly?).

• The NAV SNMP trapd should be configurable. It should perhaps per default discard unknown traps (just log them, not do anything intelligent).

• A trap NAV understands should be posted on eventq with the proper eventtype set, as done in mailin. Event handlers will be needed, as in mailin.

• It should be possible to trigger a plug in for certain traps. I.e. a script that updates the swport.link value based on link up/down traps is very interesting. Further a script that closes/opens cam entries (if traps regarding appearance/disappearance of mac addresses can be sent).

• Focus particularly on supporting traps regarding defect power (scenario where the redundant power is out).