Documentation
Download the admittedly outdated NeDi Guide
Environment
NeDi unfolds its full potential with CDP, FDP and/or LLDP capable devices in the core of your network. It can also include other network components, but it works best, when those are located at the network perimeter.
NeDi needs SNMP read access for all network hardware. Privileged CLI access can be used to get the MAC address table on IOS based switches (faster than vlan indexing and supports port security) or access points (leveraging SNR as ifmetric), but in general SNMP would be sufficient. The configurations are read via CLI as well and stored in the DB or as text files.
Network Devices
NeDi requires unique device names, since this is the primary key. It used to be the serial#, but this led to problems supporting all possible devices. The domain part is usually discarded (unless using nedi.pl -F or mapping to map2BASE in nedi.conf from NeDi 1.9 on), since CDP is not consistent with it on all devices. This could lead to problems with creating the correct device links. NeDi is capable of visualizing your network down to rack level! In order to do that, NeDi needs a certain format in the SNMP location string (separator can be set in nedi.conf with locsep):
Region;City;Building;Floor;[Room;][Rack;][RU;] [Height;][Coords]
- The building or street address can persist of several sub-buildings with a 2nd separator (e.g. _).
- The height’s only necessary, if the device comes in different sizes (e.g. a VMware ESX server).
- Coordinates (in the form of 47.800,7.800) are used in Monitoring-Map (instead of managing locations with Loced)
A couple examples:
Switzerland;Zurich;Main Station;5;DC;Rack 17;7
FL;Orlando;42 Pine St_A;54;Closet;Wallrack;1
Cities show their size based on devices:
| Icon | Size | # of Devices |
|---|---|---|
 | small | 1-9 |
 | medium | 10-49 |
 | large | 50-99 |
 | very large | 100+ |
Buildings are categorized in a similar fashion:
| Icon | Size | # of Devices |
|---|---|---|
 | small | 1-4 |
 | medium | 5-9 |
 | large | 10-19 |
 | very large | 20+ |
Network Nodes (client, server etc.)
The MAC address is used as primary key for the nodes. If you use consistent and properly terminated vlans, you can combine them with the MACs to form a new primary key, which allows the same MAC to occur in different vlans.
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:
-
Device Access defines credentials and methods how devices should be contacted.
-
Discovery allows to map IPs and ports or set borders where it should stop.
-
Backend sets DB access, but also system settings and integration with other tools
-
Messaging & Monitoring take care of polling and notification settings.
-
Nodes Related settings how nodes should be read from devices and treated afterwards.
-
GUI Settings control menu and appearance.
Many things can be fine-tuned afterwards, but those parameters should be right from the start:
Graphs
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!
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).
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:
- -p Use dynamic discovery protocols like CDP or LLDP
- -o search arp entries for network equipment vendors matched by ouidev in nedi.conf
- -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, graphs, counters and interface status (-Y adds stuff to the inventory table):
nedi.pl -SAFGgadobewituv -Yam
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:
- -v Prints heaps of information such as mac address tables, ARP-tables, interface tables or read configurations.
- -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.
- -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.