NAV has a number of back-end processes. This page attempts to give an overview of them.

The shell command nav list lists all back-end processes. nav status tells you if they are running as they should. With reference to the nav list, jump directly to the relevant section in this document:

nav list gives you this list:

• alertengine
• cricket (includes makecricketConfig, Cricket collector and cleanrrds)
• eventengine
• ipdevpoll
• logengine
• mactrace
• maintengine
• pping
• psuwatch
• servicemon
• smsd
• snmptrapd
• thresholdMon
• topology

• jobs and plugins
  All ipdevpoll's work is done by plugins. Plugins are organized into jobs, and jobs are scheduled for each active IP device individually.
• inventory job
  Polls for inventory information every 6 hours (by default). Inventory information includes interfaces, serial numbers, modules, VLANs and prefixes.
• profiler job
  Runs every 5 minutes, profiling devices if deemed necessary. NAV has an internal list of SNMP OIDs that are tested for compatibility with each device. This is used to create a sort of profile that says what the device supports - the profile is typically used to produce a Cricket configuration that will collect statistics from proprietary OIDs.
• logging job
  Runs every 30 minutes and collects log-like information from devices. At the time being, only the arp plugin runs, collecting ARP caches from routers. ARP data is logged to a table, and aids in topology detection and client machine tracking.

• cam data is not collected from ports that are connecting to other switches (as determined by the physical topology builder). Typically the cam records are stored initually before the topology is built. When topology information is in place the end time in the relevant cam records are set.
• The command line tool navclean.py offers a means of deleting old cam (and arp) entries.

The following is cut and paste from the referenced chapters in NAVMore and tigaNAV. Rewrite/translate to one text.

CAM-loggeren kjører hvert kvarter. Det som skjer da er at alle svitsjer (SW og KANT) blir hentet fra databasen og lagt i en kø. Så startes et antall tråder (24 er default) som alle jobber mot denne køen. Hver tråd sjekker om det ligger en boks i køen, og hvis så er tilfellet hentes denne ut og tråden foretar spørring med SNMP. Når dette er ferdig sjekker den køen igjen. Dersom køen er tom avslutter tråden. Alle trådene vil altså hente bokser fra køen helt til denne er tom, og da har alle resterende bokser en tråd som jobber mot dem. Dette sikrer at alle trådene hele tiden har arbeid å gjøre selv om noen bokser tar mye lenger tid å hente data fra enn andre.

–

The cam logger, responsible for the collection of MAC addresses and CDP data, has been updated to make use of the OID database. This has greatly simplified its internal structure as all devices are now treated in a uniform manner; the immediate benefit is that data collection is no longer dependent on type information and no updates should be necessary to support new types. Upgrades in the field can happen without the need for additional updates to the NAV software.

–

The cam logger collects the bridge tables of all switches, saving the MAC entries in the cam table of the NAVdb. Additionally, it collects CDP data from all switches and routers supporting this feature; the result is saved in the swp_netbox table for use by the network topology discover system.

While its basic operation remains the same, it has been rewritten to take advantage of the OID database; the internal data collection framework has been unified and all devices are treated in the same manner. Thus, data collections are no longer based on type information and a standard set of OIDs are used for all devices. When a new type is added to NAV the cam logging should “just work”, which is a major design goal of NAV v3.

One notable improvement is the addition of the interface field in the swport table. It is used for matching the CDP remote interface, and makes this matching much more reliable. Also, both the cam and the swp_netbox tables now use netboxid and ifindex to uniquely identify a swport port instead of the old netboxid, module, port-triple. This has significantly simplified swport port matching, and especially since the old module field of swport was a shortened version of what is today the interface field, reliability has increased as well.

The topology discovery system builds NAV's view of the network topology based on cues from information collected previously via SNMP.

The information cues come from routers' IPv4 ARP caches and IPv6 Neighbor Discovery caches, interface physical (MAC) addresses, switch forwarding tables and CDP (Cisco Discovery Protocol). The mactrace process has already pre-parsed these cues and created a list of neighbor candidates for each port in the network.

The physical topology detection algorithm is responsible for reducing the list of neighbor candidates of each port to just one single device.

In practice the use of CDP makes this process very reliable for the devices supporting it, and this makes it easier to correctly determine the remaining topology even in the case of missing information. CDP is, however, not trusted more than switch forwarding tables, as CDP packets may pass unaltered through switches that don't support CDP, causing CDP data to be inaccurate.

After the physical topology model of the network has been built, the logical topology of the VLANs still remains. Since modern switches support 802.1Q trunking, which can transport several independent VLANs over a single physical link, the logical topology can be non-trivial and indeed, in practice it usually is.

The vlan discovery system uses a simple top-down depth-first graph traversal algorithm to discover which VLANs are actually running on the different trunks and in which direction. Direction is here defined relative to the router port, which is the top of the tree, currently owning the lowest gateway IP or the virtual IP in the case of HSRP. Re-use of VLAN numbers in physicallyq disjoint parts of the network is supported.

The VLAN topology detector does not currently support mapping unrouted VLANs.

pping is a daemon with its own (configurable) scheduling. pping works in parallel which makes each ping sweep very efficient. The frequency of each ping sweep is per default 20 seconds. The maximum allowed response time for a host is 5 seconds (per default). A host is declared down on the event queue after four consecutive “no responses” (also configurable). This means that it takes between 80 and 99 seconds from a host is down till pping declares it as down.

Please note the event engine will have a grace period of one minute (configurable) before a “box down warning” is posted on the alert queue, and another three minutes before the box is declared down (also configurable). In summery expect 5-6 minutes before a host is declared down.

The configuration file pping.conf lets you adjust the following:

In addition you can configure debug level, location of log file and location of pid file.

Note: In order to uniquely identify the icmp echo response packets pping needs to tailor make the packets with its own signature. This delays the overall throughput a bit, but pping can still manage 90-100 hosts per second, which should be sufficient for most needs.

pping has three threads:
  1. Thread 1 generates and sends out the icmp packets.
  2. Thread 2 receives echo replies, checks the signature and stores the result to RRD.
  3. The main thread does the main scheduling and reports to the event queue.

Thread 1 works this way:
  FOR every host DO:
    1. Generate an icmp echo packet with: (destination IP, timestamp, signature)
    2. Send the icmp echo.
    3. Add host to the "Waiting for response" queue.
    4. Sleep in the configured ''delay'' ms (default 2 ms). This delay will spread out the response times, which in 
       turn reduces the receive thread queue and will in effect make the measured response time more accurate.

Thread 2 works this way:
  As long as thread 1 is operating and as long as we have hosts in the "Waiting for response" queue, with a
  timout of 5 seconds (configurable):
    1. Check if we have received packets
    2. Get the data (the icmp reply packet)
    3. Verify that the packet is to our pid. 
    4. Split the packet in (destination IP, timestamp, signature)
       If IP is wrong or signature is wrong, discard.
    5. If we recognize the IP address on the "Waiting for response" queue, update response time for the host and
       remove the host from the "Waiting for response" queue.

When thread 2 finishes the sweep is over. If hosts are remaining on the "Waiting for response" queue, we set
response time to "None" and increments the "number of consecute no-reply" counter for the host.

When thread 3 detects that a host has to many no-replies a down event is posted on the event queue.

Note that the response times are recorded to RRD which gives us response time and packet loss data as an extra bonus.

• see the NAVMore report as referenced for details

• See ThresholdMonitor

Also see the event- and alert system page.

• eventEngine is plugin based with two classes of plugins; one for eventtypes and one for physical devices. Further details in the referenced documentation.

• See referenced doc.

• See the referenced doc.

As described when given the -–help argument:

Usage: smsd [-h] [-c] [-d sec] [-t phone no.]

  -h, --help            Show this help text
  -c, --cancel          Cancel (mark as ignored) all unsent messages
  -d, --delay           Set delay (in seconds) between queue checks
  -t, --test            Send a test message to <phone no.>

Especially note the --test option, which is useful for debugging when experiencing problems with smsd.

The configuration file smsd.conf lets you configure the following:

In addition, some dispatchers need extra configuration as described in comments in the config file.

• if a rrd-file is found and is in the RRD database, leave it alone.
• if a rrd-file is found that is not in the database, check the last update-time. If the time for last update is less than 2 weeks ago, leave it alone. Otherwise delete the file.

• see referenced doc. Note that this system at one time was intended for NAVs own logs. This idea was aborted at a later stage.