This is an old revision of the document!
This document presents a list of new features we are working on from February 2007 and forwards; i.e. post NAV 3.2. This is a dynamic document - watch out for updates!
The page is loosely sorted on priority. To see what in fact is committed for new NAV releases, see links from the road map table of NAVPlanned.
Also see lower priority tasks i TaskListLowPri.
Assigned to | Morten Brekkevold | ||
Others | Stein Magnus Jodal can do the Python webfront parts | ||
Estimated time | ? hrs | ||
Start date | |||
Status | |||
Due for | NAV 3.2 |
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.
port with the new field interface (we need these fields here to support retrieving data from historic switch ports that are gone from the swport table).
Today when you add a new device of an unknown type you have to manually add the type in edit database. You also have to fill in some less than obvious fields, i.e. frequency.
Change the type table:
Make add netbox simpler:
Improve gDD:
|| Assigned to || Morten Brekkevold ||
Estimated time | ? hrs | ||
Start date | |||
Status | |||
Due for | ? |
Implement config file support.
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.
Assigned to | Morten Brekkevold | ||
Estimated time | ? hrs | ||
Start date | |||
Status | |||
Due for | ? |
When a “wanted” mac address is seen by the camlogger this sould trigger an alarm posted on the eventq. This is very useful when a certain machine is “wanted” but currently is offline.
Assigned to | Morten Brekkevold | ||
Estimated time | 2 days | ||
Start date | |||
Status | |||
Due for | ? |
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.
Assigned to | Morten Brekkevold | ||
Estimated time | 40 hrs | ||
Start date | |||
Status | |||
Due for | ? |
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.
Assigned to | Morten Brekkevold | ||
Estimated time | 40 hrs | ||
Start date | |||
Status | |||
Due for | ? |
getDeviceData, eventEngine and getBoksMacs use a homebrew logging system. gDD is a huge, complex system, where this homebrew logging library is not nearly flexible enough for hard core debugging.
Assigned to | Morten Brekkevold | ||
Estimated time | ? hrs | ||
Start date | |||
Status | |||
Due for | ? |
Assigned to | Morten Brekkevold | ||
Estimated time | ? hrs | ||
Start date | |||
Status | |||
Due for | ? |
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-plugin for ENTITY-MIB, and make sure the HP plugin does HP specific things afterwards.
Assigned to | Morten Brekkevold | ||
Estimated time | 14 hrs | ||
Start date | |||
Status | |||
Due for | 3.3 |
The CDP and TFTP fields required for equipment types are unused. A device's CDP ability can been discovered through the device's OID support classification, and the TFTP field is not used by anything in NAV.
Assigned to | Stein Magnus Jodal | ||
Estimated time | ? hrs | ||
Start date | (2007-02-16) | ||
Status | |||
Due for | NAV 3.3 |
certain device and time frame
a router/switch - very interesting data.
Assigned to | Stein Magnus Jodal | ||
Estimated time | 80 hrs | ||
Start date | (2007-03-06) | ||
Status | |||
Due for | NAV 3.3 |
(Performance improved about 75% in r3925, but a rewrite is wanted in the future.)
takes a netbox and to/from date as parameters
and time interval
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.
i.e. the machines behind swport machine tracker page.
Assigned to | Stein Magnus Jodal (and Morten) | ||
Estimated time | ? hours | ||
Start date | |||
Status | |||
Due for | NAV 3.3 |
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.
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.
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.
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 simular in NAV v2 - NTNU has a solution for their v3!
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.
Assigned to | Stein Magnus Jodal | ||
Estimated time | 40 hrs | ||
Start date | |||
Status | |||
Due for | NAV 3.3 |
name that is not a switch it entered, further no error is given if module or port names
out of range is given. Changes here alse affect the change to interface name instead of module/port. Further in accordance to FR 1556369 it should be possible to enter the switches ip address instead of name.
patch data input from the Edit Database tool.
Assigned to | John Magne Bredal | ||
Estimated time | 90 hrs | ||
Start date | |||
Status | |||
Due for | NAV 3.3 |
on link up/down traps is very interesting. Further a script that closes/opens cam entries (if traps regarding apperance/disapperance of mac addresses can be sent).
Assigned to | John Magne Bredal | ||
Estimated time | ? hrs | ||
Start date | |||
Status | |||
Due for | NAV 3.3 |
Arnold in NAV 3.1 supports taking machines off the network by setting the switchport 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 quarantene 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:
Assigned to | John Magne Bredal | ||
Estimated time | 120 hrs | ||
Start date | |||
Status | |||
Due for | NAV 3.2 and 3.3 |
Assigned to | John Magne Bredal | ||
Estimated time | 80 hrs | ||
Start date | |||
Status | |||
Due for | NAV 3.3 or later |
Assigned to | Andreas Knudsen | ||
Estimated time | 80 hrs ? | ||
Start date | |||
Status | |||
Due for | NAV 3.3? |
Assigned to | Unassigned | ||
Estimated time | 40 hrs | ||
Start date | |||
Status | |||
Due for | Post NAV 3.3 |
The idea is to create an interactive visualization where node layout is automatic and can be zoomed to any extent.
Other traffic map ideas:
funtionality. If the zoom function is good end user machines can be shown as well. The various links between the
nodes in the graph may eiter 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.
top of geographical maps (with changing detail depending on zoom level).
Also consider other enhancements to the traffic map:
Assigned to | Unassigned | ||
Estimated time | 160 hrs | ||
Start date | |||
Status | |||
Due for | Post NAV 3.3 |
NAV does not support IPv6 today. Look into support in this order of priority: