Usm peleng EN

en | ru

This function is one of the possibilities to update the activity date of an object

USM_PELENG - is a module for interrogating managed equipment in terms of FDB table (MAC address) capture.

This module is a replacement for the obsolete us_peleng module

Module Language: Perl

Current version: see page: Modules

Module Status: Paid

Required Perl modules:

Time::Local
Socket
FindBin
URI
URI::Escape
LWP::UserAgent
LWP::Protocol::https
JSON
Data::Dumper
Net::Telnet
Net::SNMP

For general information for all modules, see the page: Modules

Main Functions

• capture MAC addresses from equipment by VLAN and port
• capture ARP table from equipment (IP+MAC addresses)
• accumulate MAC address history on equipment ports with the date of the first and last address appearance. This makes it possible to search for unauthorised connections, flooding, rings, virus activity
• Updating the date of activity in the network to users and equipment whose MAC address has been found
• accumulation of a base of unknown MAC addresses
• on devices that allow to receive not only MAC-addresses, but also IP-MAC-address pair is performed MAC-address learning for these IP-addresses (if the function is enabled)
• on polled devices with which communication is established - the date of device activity in the network is updated

The method of data capture is telnet or SNMP. The method can be specified both globally in "Settings" and individually for each specific equipment. Also note that there is an option for SNMP to select v.1 or v.2 protocol for operation.

If the "Do not capture MAC addresses from UPLINK ports" parameter is enabled in the system configuration, MAC addresses for such ports will not be processed.

The module connects to one device at a time and tries to obtain information about it

Install and configure the module

1. Allocate a separate directory. A completely arbitrary one. It is better not to place it in a catalogue accessible via web. Interaction with ERP "UserSide" is performed by tools of API via http/s-protocol. This way the module is fully autonomous and can work on any separate computer in any subnet. Also create a separate directory for the module logs. Do not forget to specify write permissions for it.
2. Transfer there the files from the module archive. Rename the sample configuration file "usm_peleng.conf-example" to "usm_peleng.conf". In it, configure the parameters. The list of possible parameters is given below.
3. Check for additional perl packages that are required to run the module. Their list is given above. If you do not have them installed, the module will generate an error at startup and the perl-package will need to be installed (using CPAN or PPM).
4. In the "Settings - Modules" section, enable the usm_peleng module
5. In the switches cards, you should enable the work with the usm_peleng module
6. Start the module manually

perl usm_peleng.pl

It should start and run without errors.

7. Write the module startup into the system cron, according to the recommendations below

Clarifications:

1. When a new switch is added to the system, it automatically has the option to poll the device with the usm_peleng module enabled
2. At startup, the module processes only one device. Therefore, the system cron should be set to call the required number of copies of the module (based on the number of switches in the system and the desired polling frequency).

If you want to use the module to update the activity date of users/equipment, when specifying the number of copies of the module you should proceed from the following: in ERP "UserSide" the default network activity time is 15 minutes (i.e. this is the time after which the user/house/unit will be considered inactive). So, within 15 minutes, the modules must be able to process all devices. A module processes one device at startup. Therefore, the module will be able to process 15 devices within 15 minutes. If there are more devices, it is necessary to use the second copy of the module, the third, etc. You can run any number of copies of the module. To ensure that the simultaneous launch of a large number of copies of the module does not lead to an increased load on the database and the processor (because the same tasks will be executed during the launch) is designed parameter "$delay". By specifying in it a number of arbitrary delay, for example in "20" - you can achieve that the modules will be launched from 1 to 20 seconds in random order and the load will be distributed.

Also, if there is a large number of equipment, it makes no sense to start polling the equipment every 15 minutes. To distribute the load, you can configure the operation so that each device is polled once every 1-4 hours. This is enough in principle. And to record activity by users/ equipment, use the usm_checker module.

Example from cron of running five copies of the module:

* * * * * perl /home/usm_peleng/usm_peleng.pl &> /dev/null
* * * * * perl /home/usm_peleng/usm_peleng.pl &> /dev/null
* * * * * perl /home/usm_peleng/usm_peleng.pl &> /dev/null
* * * * * perl /home/usm_peleng/usm_peleng.pl &> /dev/null
* * * * * perl /home/usm_peleng/usm_peleng.pl &> /dev/null

In the card of the device on which the usm_peleng module is enabled, you can view the history of polling of this device by the module and the general table of device polling by clicking on the corresponding link.

Parameters

The module is configured in the usm_peleng.conf file

$usUrl - URL to ERP "UserSide"
$usApiKey - API-key to ERP "UserSide"
$logsPath - Path to the catalogue for module logs

$isSilence - Flag - hide notifications to the console when the module is running
$delay - Random time delay from 0 to n-seconds after module start. Allows you to reduce the load on the server when using a large number of modules at the same time.
$citiesList - List of identifiers of settlements (comma separated). IP-addresses of which to poll. 0 - objects without address
$isArpPolling - Flag whether to poll the ARP table from the device.

The usm_peleng module can be run with the (specify the specific device to poll) parameters

Example:

perl usm_peleng s 998

will poll the switch with ID 998

If the information is not captured/module does not work

1. It is necessary to differentiate and understand whether the module is not working or the information is not captured. In the equipment card - you should check the usm_peleng module run log by device.

2. You should make sure that community access, passwords are correct and the device itself is physically connected and working.

3. In the ERP "UserSide" itself, open the switch card and follow the "FDB table" link

4. To test - you should run the module specifically for a particular switch. For example:

perl usm_peleng.pl s 998

will start the module for switch ID: 998

Check if there are no errors in the information output.

In the log files, analyse the received information.

Run in Docker environment

If you use USERSIDE in a Docker environment, you will probably be interested in running external usm modules in separate Docker containers.

We provide a docker environment to run the usm_peleng module (the environment does not contain the module files - you need to download them from your personal account yourself).

You can download the docker environment at: https://github.com/userside/usm_peleng-docker-env/releases