This document presents a list of new features we have been working on from February 2007 till September 2007; i.e. for the NAV 3.3-release.

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

• Support the ability to except certain prefixes from data collection. Implement config file support.
• (2007-08-13) Possibly already implemented by Jostein Gogstad on his IPv6 branch. Needs further testing.

• Today the netbox.sysname value is based upon dns. If dns does not resolve the ip address is used as name. We should in addition collect the name that is configured on the device, and perhaps make it configurable in a config file what should be the primary name source used in the front end tools.
• collect system.sysLocation and sysContact as well. Store it in netboxinfo (perhaps).

• Translate networkDiscovery logging to English (bugid 1516904)
• Make the reports more available (admin tool on web or something).

When a “wanted” mac address is seen by the camlogger this should trigger an alarm posted on the eventq. This is very useful when a certain machine is “wanted” but currently is off line.

This task concerns itself with making somewhat of a “sudo” system for the NAV web UI, enabling the administrator to act as other NAV users. This idea arises from the oft requested need to edit a mortal user's alert profile. A general “sudo”-like mechanism of the web UI should not be too difficult to implement.

• A “sudo” tool will move the session's user attribute into a realUser attribute, and attach the effective account object to the session's user attribute. This should work for the entire web interface.
• The MainTemplate must be able to differentiate whether a real user is logged in, or if someone is just effectively operating as that user. MainTemplate must clearly signify this state in the interface, so the administrator knows why his/her effective privileges have been dropped.
• The “sudo” tool must have a “return to being the administrator” function, which should be available from the MainTemplate near the “logout user” and/or “currently logged in as user” elements.
• The ability to to “sudo” in the web interface should be a configurable privilege in the user admin panel.

NAV v2 had the functionality of sending delayed SMS messages. The idea was that the guard on duty should be able to sleep through less important alerts during the night. In the morning he/she should get updates on SMS. These updates should not include events that have fixed themselves during the night.

A modification of alert engine and alert profiles is needed to implement this support.

getDeviceData, eventEngine and getBoksMacs use a home brew logging system. gDD is a huge, complex system, where this homebrew logging library is not nearly flexible enough for hard core debugging.

• The Java subsystems should be refactored to use Log4j (http://logging.apache.org/log4j/).

The HP plugin apparently only supports virtual HP stacks and does not understand physical stacks (e.g ProCurve 5308). Physical HP stacks can be understood pretty well by looking at ENTITY-MIB, so it might be a good idea to implement a generic device-plug in for ENTITY-MIB, and make sure the HP plug in does HP specific things afterwards.

• (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.

• Add support for local reports.

 Separate local reports in a local file so that NAV's own reports
 are not altered. Local reports with equivalent name as the NAV
 report takes precedence. The local report does not have to copy all
 the original report variables, only the ones that are to be
 replaced.

• Make an automated report page.

 This page gives a listing of all reports defined with
 their title and a description. $description is not
 a variable today - this should be added.
 We suggest the report list is linked from the static
 report main page of today. We suggest an alphabetical
 listing.

• Implement a sum function ($sum).

 This is interesting in some reports, i.e. where we give a machine count on all
 machines on all prefixes. A total on this report will
 give the total number of machines in the network.
 This functionality was also present in NAV v2.

• Morten: Add a duplex mismatch report.

 This report should show analyze all interconnection between
 switches and look at the duplex value on each side of the
 link. If there is a mismatch a row in the report should
 be produced. Ideally this report should be empty at all times.
 The report can be produced using one (rather complex) SQL
 sentence in report.conf. We have done something similar
 in NAV v2 - NTNU has a solution for their v3! 

• Morten: Also add a spanning tree blocked ports report.

 Once again - steal from the NTNU v3 installation.

• Enhance/partially rewrite the report code base.

 The overall goal being to improve performance and code readability.
 This task may be dropped if it involves a lot of work.

• (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 yet been implemented:

• 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.

Rewrite Alert Engine (now Perl) in Python with all existing features, plus the following missing features:

• Support all operators from AlertProfiles (defined in subsystem/alertprofiles/config.php:31)
• Support subcat

The features of IP Info is mostly a subset of IP Device Center, thus IP Info should be merged into IP Device Center.

1. Add room/patch support to Machine Tracker. This is a part of SMJ4.
2. Extend IP Device Center to show IP/hostname for hosts which is unknown to NAV, just like IP Info does today.
3. Remove the IP Info subsystem.
4. Rename IP Device Center (sysname devBrowser, webname browse) to IP Device Info (sysname and webname ipdevinfo, with redirect from webname browse).
5. Change all links from /browse to /ipdevinfo.
6. Add IP Device Info search box on the front page, in addition to the existing search box at the reports main page.

• 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).

• Switch vlan in addition of shutdown of ports.

Arnold in NAV 3.1 supports taking machines off the network by setting the switch port they are connected to in shutdown. We would like to support an alternative; instead of shutting down the port, we instead change the vlan value of the port. This will allow for quarantine vlan solutions where the user is given limited network access and typically is redirected to a web page giving information on why he is taken off the network (followed by instructions on how he should proceed).

Minor changes:

• Close ports based on mac-addresses
• Open all or one when several ports are closed based on same ip/mac
• A timer for incremental closing of ports to prevent skyhigh numbers
• More information on the webpage.

• Collect more counters from the interface mib. Take a look at what UNINETTs genplot collects. For instance input ignores, output discards, interface resets.

• Re implement makecricketconfig making it more modular and easier to expand with new statistics. It is an overall goal that NAV admins should fairly easily be able to add their own set of statistics.

• Add support for wireless users statistics
  • Expand the oidDB with the new OIDs. Wireless base stations should then be classified to answer to the relevant new OIDs.
  • Build cricket config tree foe wireless. Focus on octets, errors and users.

• Add support for UPS traffic statistics collection
• Do expansion in a similar manner as for wireless.

• Add support for weathergoose statistics

• RRDbrowser is a powerful tool, but suffers from being hidden way down in the user interface. With a better, general interface to RRDbrowser, perhaps combined with sorted statistics (T9) this could be the new NAV statistics tool (which in turn can link to cricket).

• Take a look at the nav-dev posting of Sun, 21 Sep 2003 12:32:48 from faltin with title “Statistical viewer, herunder multiselect!”
• simplify this, focus on implementing the most wanted features.

• It is sometimes interesting to view a sum of underlying RRD data in one graph. An example is the sum of all wireless users in a building or on a campus, etc.

• Make a new device handler to gDD that collect interesting information from wireless base stations. In particular:

• configured channel IEEE 802.11b and 802.11g
• configured channel IEEE 802.11a
• mac address used for IEEE 802.11b and 802.11g
• mac address used for IEEE 802.11a

• Input the selected data as (var,value) in netboxinfo.

• Make reports that can view the collected data.

• Consider enhancements to IP device center in this respect.

• Make use of the Prefuse library (http://prefuse.sf.net/) to re implement the visualization of the Traffic Map component. Observe the following ideas:
  • Implement a DeviceRenderer to render node icons from a scalable SVG source file.
  • Implement a new EdgeRenderer class to render edges colored for both uplink and downlink traffic stats (just as the current version displays it).

The idea is to create an interactive visualization where node layout is automatic and can be zoomed to any extent.

Other traffic map ideas:

• Show a physical view of the network with interconnection of all network devices regardless of layer 3 and layer 2 functionality. If the zoom function is good end user machines can be shown as well. The various links between the nodes in the graph may either be a layer 3 p2p link, a layer two trunk, or a layer two specific vlan connection. Avoid using the layer three cloud that vlanplot uses, assume this always is implemented with underlying switches that NAV should discover.
  • This requires that every physical router port is connected either directly to another router (serial etc) or two a switch. If we are missing the gwport.to_netbox info we could use vlanplots layer3 view instead.

• Make the Traffic map a status monitor by introducing green and red nodes (containers, routers, switches, network clouds). Allowing for intermediate colors to reflect that a given percentage of the nodes contained are down.

• Assuming the room table has utm location information show a correct geographical layout og the map on top of geographical maps (with changing detail depending on zoom level).

Also consider other enhancements to the traffic map:

• container hierarchy / auto generate containers
• support parameters making it possible to link directly to a container
• auto layout algorithm on/off pr container
• consider showing all subnets on the top level. Possibly add a button for this.
• strengthen the admin view when moving routers around.

NAV does not support IPv6 today. Look into support in this order of priority:

1. Gather data from all routers for IPv6 router ports / prefixes
2. Complement this with a IPv6 prefix matrix
3. Gather IPv6 machine tracker data (IPv6 “arp”/neighboring cache).
4. Consider IPv6 traffic statistics (there are separate IPv6 traffic counters, we think…)
5. Look at collecting snmp data from netboxes using IPv6. This we consider far fetched.

• HP has syslog messages with four levels. Map these to equivalent cisco levels and support the HP log format so that the messages can be imported in the NAV logger database.
• The syslog parser should be made more generic, so that messages from UPSes and whatnot can be included.