Managing network infrastructure, servers or even printers? Just trying to keep track of the computers in your organization, or do you also want to know, when and where they show up and which ones got web servers installed? Have a look at this flyer for some more information at a glance.
It all started out in 2001 as a bunch of scripts to retrieve the MAC-Address tables off switches and display where nodes are connected to the network. During the next 7 years NeDi evolved at the Paul Scherrer Institute to a full blown network management framework.
I joined a major IT company in 2008 allowing me to gain a lot more insight to people’s needs managing networks outside scientific research facilities! I kept the actual work and ideas entirely apart from my professional occupation. Which meant to do any work in my spare time. Great ideas from the community and their continued support kept me motivated during some extremely busy times and made NeDi possible in its current form.
Have a look at the Services page if you’re interested in professional support, training or have feature requests.
NeDi benefits from an ever growing community. People are actively supporting the development by pinpointing problems and (even better) coming up with the fix for them. I can’t develop on every possible network device, as I cannot try every possible version of PHP and MySQL. So, if you have a problem and don’t find a fix in the forum, try to narrow it down as much as possible before seeking active support.
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.
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), 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):
The building or streetaddres 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).
Here’s an example:
Switzerland;Zurich;Main Station;5;DC;Rack 17;7
or: FL;Orlando;42 Pine St_A;54;Closet;Wallrack;1
Cities show their size based on devices:
|Icon||Size||# of Devices|
The same applies to Buildings where as important ones can be “painted” red using redbuild in nedi.conf:
|Icon||Size||# of Devices|
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.