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

File Tool can also be used as editor

The First Time

Either use the GUI module System-NeDi 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 Use dynamic discovery protocols like CDP or LLDP
  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 or the default gateway, if you haven’t added any seeds there yet.

Seedlists let you add single IPs or ranges like 10.10.1,2,3.5-100. Those ranges are expanded to single hosts. If you precede an entry with ! they’ll be removed from the seedlist (e.g. !10.10.1,2,3.11).

If you don’t want to edit seedlists you can add target(s) with -a:

nedi.pl -a 10.10.10.1-5

Using -A lets you add seeds directly from DB:

nedi.pl -Aall (queues all snmp devices)
nedi.pl -A"devos = 'IOS'" (queues all IOS devices)

Similarly -O can be used to queue ARP records matching certain MAC addresses or vendor strings:

nedi.pl -O"oui regexp 'Extreme'"  (use ~ with Postgres backend)

It’s also possible to skip certain info, to speed up the discovery. Either use -S (with many arguments) or have a  look at skippol (skip-policy) 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:

nedi.pl -SadobewitAF

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

Debugging

Test a Device

-t lets you test a particular discovery scenarios (No data will be written upon completion). If you created a complex seedlist, you can test it with -ts. This should be combined with verbose or debugging output, to actually see something:

nedi.pl -vts

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. -db Will also print out error messages and create *.db (-dv) files to store its state after the discovery. Using -dc 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.