Expand

Support for Unknown Devices

Virtually any SNMP device can be managed by NeDi and I don’t just mean reading some default MIBs. All you need is a .def file which resides in the sysobj folder. In addition CLI support can be added by following the steps in the tutorial or even editing libcli-iopty.pm, but that’s a bit trickier…

Defining Devices

If an unknown device is discovered, you can create a definition file and assign an icon to it, with that it can be properly supported within NeDi.

The easiest way is through Defgen, which can be invoked by clicking on the sysobj value in Devices-List or the triangle icon in Devices-Status. Consult the help (life-saver icon on top) or have a look at the tutorial to learn how to use Defgen.




Device Icons

In order to provide some sort of consistency while not limiting expanding device support, I’ve come up with this scheme, which should cover most of the device types out there. A few exceptions exist, mainly concerning printers and supervisor(s). Use the browser in Defgen to select the icon according to the following scheme…

Colors

The top-level distinction (vendor) is made with the main color:

Vendor Color
Cisco blue
Dell (Force10) cyan
HP green
Avaya (Nortel) orange
Extreme purple
Alcatel-Lucent yellow
Brocade (Foundry) red
Other black

Bold charactar is substituted below for the x. In addition some icons use shades (d=dark,n=normal,p=pale) to differentiate between device size:

Icons

Type Subtype Shade Icon Name
Workgroup (L2) ~12 Port pale w2xp
Workgroup (L2) ~24 Port normal w2xn
Workgroup (L2) ~48 Port dark w2xd
Workgroup (L3) ~12 Port pale w3xp
Workgroup (L3) ~24 Port normal w3xn
Workgroup (L3) ~48 Port dark w3xd
Chassis (L2) small pale c2xp
Chassis (L2) medium normal c2xn
Chassis (L2) big dark c2xd
Chassis (L3) small pale c3xp
Chassis (L3) medium normal c3xn
Chassis (L3) big dark c3xd
Switch Processor spxn
Router small rsxn
Router medium rmxn
Router big rbxn
Firewall boxed fwxn
Firewall virtual fvxn
VPN GW/HW Client vpxn
Appliance apxn
Content Switch (GW) csxn
Load Balancer lbxn
IP Phone phxn
Wlan Access Point waxn
Wlan Bridge wbxn
Wlan Controller wcxn
Sensor sexn
Video Conference System ivxn
IP Camera icxn
Bladeserver Chassis bsxn
Server (ILO) svxn
Cloud (dummy device) clxn
Fiberchannel Switch fcxn
Storage stxn
Hypervisor hvxy
Virtual Switch vsxn
ATA box (VoIP converter) atxn
DSLAM (xdsl switch) dsxn
Fiber converter fixn
Printer (color, bw) pcxn,pgxn
Stack skxn
Hub w1xn




API

NeDi’s API allows reading data from a table (only with POST method at this point). It uses query.php, which can be presented intuitively with a rewrite rule:

rewrite rule for nginx

location /api {
  rewrite ^/api/(\w*)$ /query.php?t=$1&q=$args last;
}

You need to send username (u), password (p), table (t) and an optional query (q) with each request.

I recommend using the Chrome extension “postman” for testing:
nedi-postman

As you can see, the rewrite rule assigns the path after API/ to the table (t) variable and the optional query to q…

Without rewrite rule, the API can be used like this:
nedi-postman2

Queries can be worked out with regular GUI modules. As admin, click on the ladybug in the top right corner to enter debug mode. You can click on a query to examine it further in System-Export. This export module is helpful to explore the database structure as well.

Due to the fact that queries can circumvent NeDi’s tenant filters or even be (mal)formed to write data, the user has to be in the admin group for now.