NeDi network monitoring

NeDi (Network Discovery) is an open source network monitoring tool (GNU GPL license) with optional commercial NeDi_support. There is a brief NeDi_flyer.

NeDi_logo

NeDi installation

For security reasons it is strongly recommended to configure the NeDi server with a non-public IP-address, primarily to avoid making the web server a target of attack from the Internet. It may even be advisable to put this server on an internal management subnet/VLAN where normal users are prohibited from access (at least to the web server ports 80+443). Alternatively, configure the server's firewall rules so that only specific clients can access the web server ports.

On the dedicated server for NeDi, download the NeDi tar-ball file nedi-XXX.tgz from the NeDi download page. Paying customers may download the latest version 1.7 from the NeDi_customer page.

See also the general NeDi_installation page.

NeDi installation and upgrading on CentOS and RHEL Linux

To keep this page more general, the installation as well as upgrading of NeDi on CentOS 6/7 and RHEL 6/7 Linux is documented in a separate page:

See also the general NeDi_installation page.

Initial configuration of NeDi

This section explains how to get started initially with setting up your NeDi installation.

Start using the NeDi GUI

Navigation of the NeDi GUI is explained in the page http://www.nedi.ch/documentation/the-gui/.

NeDi web page login and password

Go the the NeDi server web page (https://nedi.example.com in the above example) and log in as user admin with password admin.

Change the admin password immediately:

  • When logged in, go to the User->Profile page (/User-Profile.php) for the admin user.
  • In the Status/Password "padlock" fields type in old and new passwords and press the Update button.
User profiles

You should update the User->Profile page for the admin user, and for any other user which you choose to create, for at least these fields:

  • E-mail address for receiving E-mails from NeDi.
  • SMS text message telephone number (if you want to set up an SMS gateway later).
  • Time zone.

New user accounts are created in the User->Accounts window. Here you can also assign access rights to the users. The default user password is the same as the username.

Network Discovery with NeDi

Network discovery by means of SNMP is documented in NeDi_documentation. However, NeDi first needs a little configuration.

Configuration of nedi.conf

The NeDi main configuration file /etc/nedi.conf should first be configured:

  • Set SNMP public and private communities:

    comm public
    comm <secret read-write SNMPv2 community>

    The public is the default SNMP read-only community name, but you may want use a different read-only community in your devices and in NeDi.

  • Only discover devices where ip address matches this regular expression:

    netfilter ^192\.168\.0|^172\.16
  • Address where notification emails are sent from:

    mailfrom nedi@example.com
  • Add IP addresses, IP ranges or host names to the file /var/nedi/seedlist, for example:

    10.13.6.2-64           public
    myserver.example.com   public
    myprinter.example.com  public

    The 2nd column (public) is the default SNMP read-only community name, but you may want use a different read-only community in your devices and in NeDi.

  • All graphs are generated using RRDtool. In NeDi 1.5 some new features available only in RRDtool 1.4 and higher are by default configured:

    rrdcmd rrdtool new

    If you have RRDtool 1.3 or older (CentOS6/RHEL6), remove the new keyword.

Running initial device discovery

Read the NeDi_documentation page section The First Time. 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 OSI_model Layer 3 devices.

A run without any options will result in a plain static discovery using the seedlist file, or the default gateway (router) if you haven’t added any seedlist file entries yet. First use the CLI and the -v option to closely follow the discovery.

Please note that -o requires that you define the ouidev parameter in nedi.conf. It seems that this option is only useful if you want to restrict device discovery to certain vendors while avoiding, for example, Cisco devices.

Run static discovery (verbose: -v) as the nedi user:

su - nedi
./nedi.pl -v

When you are satisfied with the result, you may perhaps want to try dynamic discovery:

./nedi.pl -v -p

SNMP test with snmpwalk

The snmpwalk command is installed by:

yum install net-snmp-utils

For command options see man snmpcmd.

To test that you can read a switch using SNMP use, for example, this command:

snmpwalk -Os -c <community-string> -v <protocol-version> <device-address> system

For example, on a Linux host test the localhost:

snmpwalk -Os -c public -v 2c localhost system

For a remote system b307-XXX:

snmpwalk -Os -c public -v 2c b307-XXX system

Generate device definitions for unknown devices

This part is really optional: Some switch devices may show up as grey icons (for example grey)in the Devices-List.php (Devices->List menu) because they are unknown to NeDi. The solution to this problem has been described in a Defgen_Tutorial video.

To configure NeDi device definitions for an unknown device:

  1. Click on the grey device icon grey to go to the Devices-Status.php page.
  2. In the Summary pane, click on the Edit Def File icon geom to go to the Other-Defgen.php page.
  3. View the Defgen_Tutorial video Chapter 1 (for a chassis switch go to Chapter 2 at about 19:15 min.).
  4. In the Main pane look at the SysObjId field, below it are "similar" device definitions indicated by geom icons. Click on one of the closest values to the SysObjId field to load its values into the page, and then follow the Defgen_Tutorial video.
  5. When the page has been completed, click on the Write button to write the device definition file to the server's disk.
  6. Then click on the Discovery icon radr to make NeDi rediscover the device in question.

After the next scheduled NeDi network discovery has been run, all switches of this type should appear correctly in the Devices->List.

Contribute device definitions to NeDi

As a courtesy to the NeDi community, when you have created and tested device definitions for a hitherto unknown device, please contribute the definition file by E-mail:

  • In the Other-Defgen.php page which you used before, click on the mail icon mail to E-mail the definitions to def@nedi.ch.

Switch configuration backup

Switch configurations can be backed up from the GUI or the CLI. Configurations will be stored in directories under /var/nedi/config/.

Using the GUI Devices->List, click on a given device to go to its Devices-Status.php page. In the Summary pane find the Configuration line to view the backup status. To make a new backup click on the Configuration Backup icon radr.

If using the CLI as user nedi the backup command learned from the GUI is:

/var/nedi/nedi.pl -v -B0 -SWOAjedibatflowg -a <device-IP>

Using NeDi

This section explains how to perform some common tasks. Help information for each page is in the Help icon Help.

Locating a MAC address

A common and important task is to locate the switch device and port which a particular node MAC address is connected to:

  • Go to the Nodes->Status page.
  • Enter the node MAC address and press Show.

After a few seconds the requested switch port information for this MAC is displayed.

Monitoring specific devices in Devices-List

If you want NeDi to generate notification events or alerts for certain devices in the Devices-List use this procedure:

  1. In Devices-List select a set of devices using the upper left selector, for example, Device Type ~ 2530. The press the Show button to display your list.
  2. Verify the device list, and if it's OK press the Monitor button. Now NeDi will begin to monitor events from these devices.
  3. To configure any desired actions on events, go to the Monitoring-Setup page.
  4. In the Monitoring-Setup pane labelled Filter select once more the same devices as in 1., for example, Device Type ~ 2530.
  5. In the Monitor pane select the type of test you want to perform for the selected devices. For example, replace Test-> by ping. Then select the kind of alert desired, for example, replace Alert-> by Mail in order to send E-mails to the logged-in user.
  6. In the Events pane Forward field, select the minimum event level desired for alerts to be sent, for example, replace Level by Warning.
  7. Press the Update button to confirm your changes.

Some hints:

  • For network switches, it is better to use Test->uptime in item 5. above, so that you will be alerted when switches are rebooted.

  • In order for E-mails to be sent to you, your E-mail address must be defined in the User-Profile page.

  • Monitoring Test alerts can be generated from the nedi user's CLI (NeDi version 1.4 and above):

    ./moni.pl -vc200

Discovery Notifications "no working user"

Some of your monitored devices may not permit CLI user logins with SSH/telnet (for example, you may not know the password). This may cause Discovery Notifications E-mails complaining about inability to access the device CLI:

<device-name>  CLI Bridge Fwd error: no working user
<device-name>  Config backup error: no working user

There doesn't seem to be any simple way to configure do not log in to this device. In stead you must modify the device discovery options for the device:

  1. In the Monitoring-Setup page select the device.
  2. In the column Events there is an icon radr called notify (when you hover the mouse over it). Here you enter the following device discovery options:

    adefijlmnopstw

    and press the Update button. Verify that the device Discover column now contain your new options.

These options explicitly omit the letters b (backup) and c (CLI). The default values are defined in nedi.conf in the Messaging & Monitoring option notify. Hopefully this should eliminate the above CLI warnings.

Adjusting alert thresholds

In the Monitoring-Setup (NeDi 1.6 and older) or Devices-List (NeDi 1.7 and newer) page you can adjust various alert Threshold values.

Click on the Edit threshold icon file field in the top pane next to the Show button:

  • CPU,
  • Temperature,
  • ARP_poison (ARP entries per IP to detect poisoning on routers),
  • Memory,
  • PoE (Power over Ethernet),
  • Supply
Latency Warning alerts

The default network Latency Warning alert is set at 100 milliseconds in nedi.conf:

latency-warn  100

Unfortunately, you can't change the latency value for already discovered devices in nedi.conf.

The solution to this problem is rather cryptic:

  1. You must go to the Monitoring-Setup page and select which devices to modify.
  2. In the Monitor heading in the top pane there is a field with no icon next to it: If you hover the mouse over this field, a text Latency Warning [ms] is shown.
  3. Click on the field's up-arrow selector to increase the value. Then click on the Update button.

Now you should see the new Latency Warning value in the device column under the Statistics heading.

Printer supply alerts

NeDi reads the printer supply levels (toner etc.) by SNMP from any printer devices monitored. If any supply level is below the notification limit (default value: 5%), an alert will appear in the Discovery Notifications E-mail sent by NeDi.

To remove these often superfluous notifications go to the Monitoring-Setup (1.6) or Devices-List (1.7) page and select the desired printers. Then edit the Supply Alert threshold icon file field to insert a value of 0, then press the Update button.

Discarding "Node changed IP and name" events

If your network has nodes (servers) with multiple IP addresses assigned to a single network interface, NeDi will report (in Monitoring-Events) in every discovery cycle events similar to this:

Node <MAC> changed IP to <IP> and name <DNS>

where MAC, IP and DNS will be specific to the nodes in question.

This is just annoying "noise" which we would like NeDi to discard, because it's perfectly normal. One usage scenario will be multiple tagged VLANs on an interface. To configure a RHEL6/CentOS6 network interface for VLAN, see 9.2.6. Setting Up 802.1q VLAN Tagging (see also Configure an Ethernet interface as a VLAN trunk (Red Hat)).

You can force NeDi to discard all such events in the Monitoring-Setup page:

  1. Select all relevant switch devices.
  2. In the Events column Syslog, Trap, Discover bell icon.
  3. Select Discard and Level=Notice.
  4. In the Filter abc field enter the text:

    changed IP to
  5. Press the update button.

The new filter will be shown in the Events Action column.

Notification: did not receive any traffic did not send any traffic

We have seen some cases where NeDi discovery sends E-mail notifications similar to:

1) switchA    Port LLDP:switchB,port   did not receive any traffic did not send any traffic

If this doesn't cease, it's actually a problem on one or both switches. The switch port counters have stopped incrementing while traffic is flowing. One can log in to both affected switches and display real-time port counters to determine which switch is at fault.

Solution: Reboot the switch with broken port counters.

Monitoring specific devices in Nodes-List

NeDi can also generate notification events or alerts for nodes in the Nodes-List, in addition to devices in the Devices-List.

Example nodes could be:

  • Switches/routers which do not have or do not permit SNMP Get operations.
  • Printers without SNMP.
  • Servers without SNMP.
  • Other devices such as PCs, cameras or whatever.

Use this procedure:

  1. In Nodes-List make a search to uniquely list the node, for example, by its IP address.
  2. Verify the node list, and if it's OK press the Monitor button.
  3. Follow steps 3-7 in the above Devices-List procedure.

Geographical visualization of device locations

From the NeDi_about page:

  • 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 as defined in the device's SNMP configuration. The format used by NeDi is:

Region;City;Building;Floor;[Room;][Rack;][Rack Unit position;][Height in RUs]

(The separator character ; can be modified in nedi.conf with locsep).

The building or street address can consist of several sub-buildings with a 2nd level separator (e.g. _). Example:

Switzerland;Zurich;Main Station_A;5;DC;Rack 17;7

The resulting device location maps can be viewed in multiple pages:

  • The Topology-Map page: Click on your Region name, then explore the map down in the City and Building levels.
  • The Topology-Table and Monitoring-Health pages: Your Buildings will be shown, then explore the Floors and Rooms down to the device level. Location errors will also be shown.

In the room view displaying racks, the default number of rack columns is 8. This may be too wide for your browser, so adjust the number of rack columns in your User-Profile page in the field icon # Columns (0-31). A number of 5 columns may be suitable.

There is an instructive Topology_Showcase video, which also describes the use of maplo and nam2loc in nedi.conf.

Changing a device SNMP community name

If you decide to change a device SNMP community name, for example, the default SNMP read-only public community, the NeDi database must be updated manually, since it doesn't help to reconfigure the nedi.conf or seedlist files with the new community name - updating this information seems to be ignored.

You have to run this command for each IP-address whose SNMP community name gets updated:

nedi.pl -a <IP-address> -C <new-community-name> -SAFGgadobewitjumpv

Reports and traffic loads

Network utilization reports

To get an overview of the utilization of your subnets, either in terms of number of nodes, or in terms of which IP-addresses are in use, go to the Reports->Networks page.

Select either Network Distribution or Network Utilization and click the Show button.

Network maps including traffic load

Go to the Topology-Map page:

  1. In the Filter pane select the locations and/or devices you want to display.
  2. In the Main pane select:

    • Size&Format: select type png and the image size you want.
    • Map Type abc: select Devices and flat
  3. In the Layout pane select the Connection Information type you want displayed, for example:

    • Bandwidth displays link bandwidth.
    • Link Load displays link load in percent.
    • Traffic: Small displays small load graphs for the past week.
  4. In the Show pane you can add device IP address, location, etc.

Finally press the Show button to generate the network map image.

Interface reports (traffic load)

To monitor the network traffic load of devices, use the Devices-Interfaces page:

  1. In the Interface-List pane select the Device Name you want to monitor.
  2. In the scrollable list of columns, select all the columns you want, for example: Total traffic Inb, Total traffic out, Last traffic Inb, Last traffic out, Last Broadcasts Inb, IF graphs.
  3. In the Limit icon form pull-down list, select the maximum number of interfaces to display.
  4. Click the Show button.

In each column heading there is a triangle/arrow icon: Click the triangle to sort the columns in ascending/descending values.

Node reports (traffic load)

To monitor the network traffic load of nodes (for example, to find nodes that generate too much traffic), use the Nodes-List page:

  1. In the scrollable list of columns, select all the columns you want, for example: Total traffic Inb, Total traffic out, Last traffic Inb, Last traffic out, Last Broadcasts Inb, IF graphs.
  2. In the Limit icon form pull-down list, select the maximum number of interfaces to display.
  3. Click the Show button: The node names and IP addresses connected to each switch interface is shown.

In each column heading there is a triangle/arrow icon: Click the triangle to sort the columns in ascending/descending values.

If you want to restrict the node list to a specific switch:

  • In the Nodes-List pane select the Device Name you want to monitor.

Mapping MAC address to IP address

Network switches at OSI_model Layer 2 operate only on the Ethernet MAC_address and are in principle ignorant about the IP_address of nodes on the network. Then how may NeDi learn about the IP_address of nodes on the network by speaking only to network devices?

Each computer maintains its own table of the mapping from Layer 3 addresses (e.g. IP_address) to Layer 2 addresses (e.g. Ethernet MAC_address). This is called the ARP cache. Your network Router works at the Layer 3 IP_address level and forwards packets between local and remote networks, hence it must have ARP cache information about all its network interfaces.

NeDi will read the ARP cache information from your Router and all other SNMP capable devices in your network, and hence NeDi can build up a database of ARP cache information internally and present it to you.

In some cases your Router may not contain complete ARP cache information of each and every device, and you need to help NeDi with additional ARP cache data. In this case you first want to run the arpwatch utility described below to accumulate an ARP cache database.

It is necessary to configure in nedi.conf:

arpwatch /var/lib/arpwatch/arp.dat*

Then execute this command:

./nedi.pl -N arpwatch

to make NeDi read in your arpwatch database. Check the list of node IP and MAC addresses in the Nodes-List page. If successful, you could run this command regularly (e.g., once per day) from crontab.

Note: If your NeDi version is too old (<= 1.5.038) then you must add the argument 0 to the misc::ArpWatch() call in nedi.pl at line 182:

if($opt{'N'} =~ /^arpwatch/){
      &misc::ArpWatch(0);

Using the arpwatch utility

For a CentOS 6 Linux server to work with ARP caches, install the arpwatch package and its arpfetch script, as well as some tools in the arp-scan package:

yum install arpwatch arp-scan
cp -p /usr/share/doc/arpwatch-*/arpfetch /usr/local/bin/

Now you can inquire any SNMP device (in particular your Router) about its ARP cache:

arpfetch <IP-address> public

where public is just a default SNMP community name (you may be using a different community name).

Updating ethercodes.dat Ethernet vendor codes

You may perhaps want to update the Ethernet vendor codes in /var/lib/arpwatch/ethercodes.dat (dated 2010) to a more recent version, but unfortunately no up-to-date ethercodes.dat file seems to be available.

Update May 2015: Arpwatch ethercodes.dat have now become available from this site:

Generating ethercodes.dat from IEEE OUI Data or Nmap MAC Prefixes

Updating ethercodes.dat is actually a little involved, since the official IEEE_OUI file has become somewhat inconsistent over the years. In stead it is recommended to download from the Sanitized IEEE OUI Data (oui.txt) page. Another possibility is to use the arp-scan tool get-oui (see man get-oui)

The arpwatch requirement is similar to the Nmap MAC Prefixes file, so you can generate ethercodes.dat with these commands:

wget --timestamping http://linuxnet.ca/ieee/oui/nmap-mac-prefixes
awk '{ mac = substr($1,1,2) ":" substr($1,3,2) ":" substr($1,5,2); $1=""; printf("%s\t%s\n", mac, $0)}' < nmap-mac-prefixes > /var/lib/arpwatch/ethercodes.dat

For automated updating you can create this Makefile:

/var/lib/arpwatch/ethercodes.dat: nmap-mac-prefixes
        awk '{ mac = substr($$1,1,2) ":" substr($$1,3,2) ":" substr($$1,5,2); $$1=""; printf("%s\t%s\n", mac, $$0)}' < $< > $@
nmap-mac-prefixes: FRC
        wget --timestamping http://linuxnet.ca/ieee/oui/nmap-mac-prefixes
FRC:

and run make.

Optional: There is also an official IEEE_IAB file (Individual Address Blocks). Each block represents a total of 2^12 (4,096) Ethernet MAC addresses. This file may be downloaded using the arp-scan tool get-iab (see man get-iab).

The arpwatch daemon

Configure the file /etc/sysconfig/arpwatch, changing the default recipient root to - in order to suppress E-mails:

OPTIONS="-u arpwatch -e - -s 'root (Arpwatch)'"

Start the arpwatch daemon (also at boot time):

chkconfig arpwatch on
service arpwatch start

ARP cache data will be collected in the files /var/lib/arpwatch/arp.dat*, and those files will be refreshed every 15 minutes by the arpwatch daemon (previous files are renamed with a "-" extension).

However, this only works if your server has a single default network interface, such as eth0. If you have multiple network interfaces, you must modify the arpwatch init-script as described in arpwatch on multiple interfaces. Every network interface to be monitored requires a separate instance of the arpwatch daemon. Download an improved arpwatch init-script to replace /etc/rc.d/init.d/arpwatch. For convenience we have attached a copy of the arpwatch-init file.

Add a new INTERFACES variable to /etc/sysconfig/arpwatch, for example:

INTERFACES="eth0 eth1"

Now start the arpwatch service as above.

Configure NeDi in nedi.conf to read the ARP cache data:

arpwatch        /var/lib/arpwatch/arp.dat*
arpwatch bugs

The arpwatch code is dated around 2006, see the LBL homepage, and therefore has a number of bugs that get fixed by various Linux distributions. One annoying bug is that the arpwatch daemon will report all DHCP lease renewals in the syslog similar to:

arpwatch: changed ethernet address 0.0.0.0 0:14:5e:55:70:25 (0:14:5e:55:c2:6a)

See this report.

To remove this bug the following patch in the arpwatch code db.c added at line 95 seems to do the trick:

/* Ignore 0.0.0.0 ip address */
if (a == 0) return (1);

The db.c_patch file is attached.

Hopefully this patch may be accepted by distributions. See also the Debian bug list for arpwatch.

To patch and rebuild the CentOS .src RPM package:

rpm -i arpwatch-2.1*.el6.src.rpm
(to do)

Kernel ARP cache

If the number of network devices (cluster nodes plus switches etc.) approaches or exceeds 512, you must consider the Linux kernel's limited dynamic ARP cache size. Please read the man-page man 7 arp about the kernel's ARP cache. Documentation on the net:

If the soft maximum number of entries to keep in the ARP cache, gc_thresh2=512, is exceeded, the kernel will try to remove ARP cache entries by a garbage collection process. This is going to hit you in terms of sporadic loss of connectivitiy between pairs of nodes. No garbage collection will take place if the ARP cache has fewer than gc_thresh1=128 entries, so you should be safe if your network is smaller than this number.

The best solution to this ARP cache trashing problem is to increase the kernel's ARP cache garbage collection (gc) parameters by adding these lines to /etc/sysctl.conf:

# Don't allow the arp table to become bigger than this
net.ipv4.neigh.default.gc_thresh3 = 8192
# Tell the gc when to become aggressive with arp table cleaning.
# Adjust this based on size of the LAN.
net.ipv4.neigh.default.gc_thresh2 = 4096
# Adjust where the gc will leave arp table alone
net.ipv4.neigh.default.gc_thresh1 = 2048
# Adjust to arp table gc to clean-up more often
net.ipv4.neigh.default.gc_interval = 2000000
# ARP cache entry timeout
net.ipv4.neigh.default.gc_stale_time = 2000000

Please change the numbers according to your network size: The value of gc_thresh1 should be greater than the total number of nodes in your network, and the other values gc_thresh2 and gc_thresh3 should be 2 and 4 times gc_thresh1. The values of gc_interval and gc_stale_time (in seconds) should be large enough to retain ARP cache data for a useful period of time (several weeks).

Then run /sbin/sysctl -p to reread this configuration file.

Receiving SNMP traps

Devices can be configured to send SNMP_traps to one or more SNMP servers whenever events occur. An SNMP server can be configured to receive and process such traps, see the tutorial TUT:Configuring_snmptrapd.

The NeDi SNMP trap handler is /var/nedi/trap.pl. Configure it as follows:

  • Put this in /etc/snmp/snmptrapd.conf for NeDi to receive traps for the public community:

    authCommunity   log,execute,net public
    traphandle      default   /var/nedi/trap.pl
    # Do not write traps to syslog (will be handled by NeDi trap.pl)
    doNotLogTraps yes
  • Change the daemon options in file /etc/sysconfig/snmptrapd so that only critical (and higher) traps are logged:

    OPTIONS="-Ls2d -p /var/run/snmptrapd.pid"

    See man snmpcmd section LOGGING OPTIONS.

  • Alternatively, snmptrapd may log to a separate syslog file by:

    OPTIONS="-Lf /var/log/snmptrapd.log -p /var/run/snmptrapd.pid"

    You must create this logfile and set its SELinux context:

    touch /var/log/snmptrapd.log
    chcon --reference=/var/log/messages /var/log/snmptrapd.log
  • Start the service:

    chkconfig snmptrapd on
    service snmptrapd start

Incoming SNMP_traps will be added to Monitoring-Events.

Upon receiving a trap, the script will check whether a device with the source IP is a device monitored by NeDi. The default event level will be set to 50 if the device is in NeDi, otherwise it is set to the low value of 10.

Firewall configuration allowing SNMP traps to be received on port 162 must be configured in /etc/sysconfig/iptables:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 162 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 162 -j ACCEPT

and the iptables service restarted.

Customizing trap.pl for SNMP trap alerts

Please note this comment by the author in trap.pl:

The script conaints some basic mappings to further raise authentication and configuration related events.
Look at the source, if you want to add more mappings. Trap handling has not been further pursued in favour of syslog messages.

Here are some simple customizations of trap.pl which you may find useful:

  • Use level=0 to ignore selected events:

    if($info =~ s/IF-MIB::ifIndex/Ifchange/){
            # We want to ignore interface up/down events
            $level = 0;
    ...
    if ($level > 0) {       # $level == 0 means: ignore this event
            my $mq = &mon::Event(1,$level,'trap',$tgt,$tgt,"$info","$info");
            &mon::AlertFlush("NeDi Trap Forward for $tgt",$mq);
    }

Test the trap functionality by sending a test trap, see the SNMP tutorial TUT:snmptrap:

snmptrap -v 1 -c public <nedi-server> '1.2.3.4.5.6' '192.193.194.195' 6 99 '55' 1.11.12.13.14.15  s "teststring"

Configuring devices to send SNMP traps

Devices must be configured explicitly to send SNMP_traps to SNMP servers. In these examples we use the default community public, but you may be using a different community name.

The syntax for HP ProCurve switches may be:

snmp-server host <IP-of-server> community "public" trap-level not-info
snmp-server host <IP-of-server> "public" not-info              # Used on some older ProCurve models
snmp-server host <IP-of-server> "public" critical              # To avoid login/logout traps being sent

HP H3C/3Com switches may use this syntax:

snmp-agent target-host trap address udp-domain <IP-of-server> params securityname public

IT-wiki: NeDi (last edited 2018-04-13 07:20:54 by OleHolmNielsen)