Documentation

Preparation

Make sure you edit nedi.conf before starting to discover your network. The configuration should be self explaining.It’s divided into sections which are:

  1. Device Access defines credentials and methods how devices should be contacted.
  2. Discovery allows to map IPs and ports or set borders where it should stop.
  3. Backend sets DB access, but also system settings and integration with other tools
  4. Messaging & Monitoring take care of polling and notification settings.
  5. Nodes Related settings how nodes should be read from devices and treated afterwards.
  6. GUI Settings control menu and appearance.


Many things can be fine-tuned afterwards, but those parameters should be right from the start:

 Graphs

PoE load at PSI during the VoIP migration. Yes, those are several hundred IP phones!

rrdstep defines the discovery interval. Make sure it always matches your crontab schedule. Most importantly are the graphs created with this value. This means if you change this interval, you’d need to delete all RRDs and have NeDi recreate them!

Find the weekend and the lunch-breaks of the students at ETH in Zurich. The green area shows first seen nodes...

In order to find a good value, you’ll need some testing. Depending on the device types, discovery settings and the connection, around 20 devices per minute can be discovered (this is just a ballpark figure!). You can create multiple discovery tasks, if you separate and start them manually for now, but this should be automated at a later stage. For a simple setup and a network with around 500 devices an hourly discovery and a resulting rrdstep of 3600 is recommended.

CLI access

login credentials for devices should be set correctly, if you want to use CLI access with nedi (e.g. to backup configs). If the login fails, the cliport of the device is set to 1, preventing further login attempts. This can be reset via Devices-Status.

Use System-Files to edit nedi.conf and the seedlist to define starting points (otherwise NeDi will use the default gw).

File Tool can also be used as editor

The First Time

Either use the GUI module System-NeDi (but I’d really use this for small networks or testing single devices only) or start it directly from the CLI. Make sure you’re doing the latter as the same user as you run the crontab with or RRDs won’t get updated correctly. You’ll probably get the best results, with using the CLI and the -v options to closely follow the discovery.Several options define how your network should be discovered:

  1. -p Dynamic discovery protocols
  2. -o search arp entries for network equipment vendors matched by ouidev in nedi.conf
  3. -r use route table entries of L3 devices

A run without any options will result in a plain static discovery using the Seedlist. Make sure you only add seeds which won’t be found otherwise in order to avoid unnecessary delays.

It’s also possible to skip certain info, to speed up the discovery. Either use -S (with many arguments) or have a  look at skipif in nedi.conf. For example, if you just want to collect an network device inventory, you’re probably not interested in the connected nodes, counters and interface status.

You can specify the seedfile to be used with -u and even the config with -U, with that you can run discoveries on different parts of your network.

Debugging

Test a Device

-t lets you examine a particular device (No data will be written upon completion). This option can also be combined with verbose or debugging output.

Discovery

If you encounter problems, make sure you understand what you’re looking for. Any discovery related problems, such as dynamic discovery protocols, authentication or just properly identifying devices can be debugged with -d and -D:

  1. -v Prints heaps of information such as mac address tables, ARP-tables, interface tables or read configurations.
  2. -d Will also print out error messages and create *.db files to store its state after the discovery. This options also logs CLI access to input.log and output.log. Open 2 more terminals and tail -f to them in order to debug CLI problems.
  3. -D on the other hand should only be used on it’s own. It will not discover your network, but rather use the previously generated *.db files to restore its state. Functions to be debugged can be uncommented at the beginning of the script (This option is intended for developers only).


Everything Looks Good

Now use System-Files or edit the crontab file directly to schedule discovery tasks. You’re ready to start managing your network with NeDi with the GUI.