Network Administration Visualized 4.3.1
Milestone information
- Project:
- Network Administration Visualized
- Series:
- 4.3
- Version:
- 4.3.1
- Released:
- Registrant:
- Morten Brekkevold
- Release registered:
- Active:
- No. Drivers cannot target bugs and blueprints to this milestone.
Activities
- Assigned to you:
- No blueprints or bugs assigned to you.
- Assignees:
- 8 John-Magne Bredal, 7 Morten Brekkevold
- Blueprints:
- No blueprints are targeted to this milestone.
- Bugs:
- 15 Fix Released
Download files for this release
Release notes
=======
Network Administration Visualized release notes
=======
Please report bugs at https:/
existing bug reports, go to https:/
If you are upgrading from versions of NAV older than 3.7, please refer to the
release notes of the in-between versions before reading any further.
Known problems
==============
The recommended SNMP library for use with ipdevpoll is `pynetsnmp`. If you
choose to go with the original TwistedSNMP, the latest version (0.3.13)
contains a bug that manifests in table retrieval operations. Timeouts and
retries aren't handled properly, and this may cause slow or otherwise busy
devices to be bombarded with requests from NAV. The `contrib/patches`
directory contains a patch for TwistedSNMP that solves this problem. The
patch has been submitted upstream, but not yet accepted into a new release.
NAV 4.3
=======
To see the overview of scheduled features and reported bugs on the 4.3 series
of NAV, please go to https:/
Dependency changes
------------------
There are none (unless you are a developer, then you should upgrade to the
latest version of pylint).
Data model changes (chassis, serial numbers, virtual devices, etc.)
-------
The 4.3 release changes NAV's data model in a fundamental way. Previously, NAV
would equate an IP device (a Netbox) with a piece of physical hardware, a
chassis, possibly with a retrievable serial number. This has become a rather
antiquated view in modern computer networking, where multiple virtual
components can be built from a single hardware unit, or a virtual device can
be built by stacking multiple hardware units.
The old data model would require each IP Device to have a unique serial
number, and also for any module in any IP Device to have a unique serial
number among all modules in all IP Devices.
NAV no longer has these restrictions. The hierarchy of physical entities
within an IP Device are collected from the ENTITY-
available, and all stored in the NAV database. NAV would previously only use
parts of this information.
A SNMP-less IP Device will no longer have a corresponding (physical) Device
entry, while a multi-chassis stack (like a Cisco VSS) will have all its
chassis registered in the database.
A set of Cisco VDCs defined within the same hardware unit will all present
themselves as physically identical to the hardware unit. Previously, this
would work poorly with NAV, because if its uniqueness requirement on serial
numbers.
Next, we aim to write support for collecting this type of hardware information
from Juniper devices, which, as of this writing, only support proprietary MIBs
to provide this information.
Bulk import format change
~~~~~~~
Because of the changed data model, the serial number column in the IP Device
(Netbox) bulk import/dump format has been removed. If you have old dump files
that you want to bulk import into NAV 4.3's SeedDB, you must remove the serial
number field from these files first.
The new chassisState family of alerts
-------
NAV 4.3 introduces the ``chassisState`` event type, with ``chassisDown`` and
``chassisUp`` alerts. These can be subscribed to in Alert Profiles.
In a scenario where an IP Device is a stack of multiple physical chassis, NAV
will produce ``chassisState`` events if a previously known chassis disappears
or reappears in the stack. A chassis that is removed from a stack on purpose
must be manually deleted from NAV, just as purposefully removed modules have
always needed to be.
The eventengine will further suppress ``moduleDown`` alerts for modules that
reside within a chassis that has an active ``chassisDown`` alert. Previously,
a Cisco VSS that broke down would cause NAV to report a slew of ``moduleDown``
alerts, one for each of the modules in the lost chassis.
Deleting out of service modules and chassis
-------
When you physically remove a module to take it out of service, NAV will
produce a ``moduleDown`` alert. To remove the module from NAV's inventory, you
would previously need to go to the Device History tool and remove it from the
"Delete module" tab.
In NAV 4.3, deleting modules and (now) chassis, and their corresponding alerts
is directly available as one of the bulk actions on the status page.
Link, module and chassis status verification
-------
As part of the ipdevpoll ``inventory`` job, the ``modules`` and ``entity``
plugins (which both collect inventory and performs status check against known
inventory) only run every 6 hours. This is not often enough to provide a
continuous status verification (and updated alerts).
In response to this, the 5-minute interval ipdevpoll ``linkcheck`` job has
been renamed to the more generic ``statuscheck``, and the ``modules`` and
``entity`` plugins now additionally run as part of this job.
