https://www.nectus5.com/wp/wp-content/uploads/2018/02/logo.png00Web Masterhttps://www.nectus5.com/wp/wp-content/uploads/2018/02/logo.pngWeb Master2019-07-03 09:58:132019-07-03 12:06:12Standalone NetFlow and Syslog VM OVA File (Clickhouse DB)
Nectus Server 1.55 adds feature to monitor some system parameters on hosts running Linux. Enabling this feature for your infrastructure requires two steps:
Configuring of Nectus Server;
Installing and configuring of Nectus remote agents on target Linux machines.
This guide describes steps for Nectus Server configs. Installing and configuring of Linux remote agents are described here.
Linux monitoring integration
Choose the following menu item from the Nectus GUI to set global Linux monitoring parameters.
This will open the next window:
Agent mode determines whether the agent runs in passive mode (when it waits for an incoming connection from the server and then collects the required metrics) or in active mode when the agent connects to the server pro-actively and sends the collected data.
Server TCP port sets the server port number for incoming connections from the agents running in active mode. If you set Agent mode to passive then this value is not used.
Pre-shared Key determines the secret key used to encrypt and decrypt messages between Nectus Server and the monitoring agents. You can set string of any length but recommended length is from 8 to 16 characters. The exactly same key should be set in all agents’ configuration files (parameter SERVER_PRESHARED_KEY, see details here).
Click OK to save configured parameters.
Select “Linux Monitoring Settings” from the “Monitoring” menu to configure your monitoring profiles for Linux machines.
Click “Create” to create a new monitoring profile:
In the following form enter the name of your profile and choose metrics you would like to monitor:
Configure the necessary metric parameters like minimal and maximal thresholds, alerting etc.
You can create any number of profiles and assign each of them to different group of Linux machines.
Linux Servers
Select “Linux Servers” from the “Inventory” menu to configure groups and servers to be monitored.
Click “Create new Group” in the next form:
Enter “Group Name” for the new group, select “Enable monitoring” and choose the desired Monitoring Profile for this server group:
Also select the appropriate alert recipients in this form.
You can create any number of monitoring groups if you need to apply different profiles or alert recipients for different server groups.
When you have finished with the groups switch to the next tab “Servers” in the same form and click “Add Server” to add a Linux server to be monitored:
In the next window enter the Hostname (optional, it will be obtained later during the monitoring process), IP address, TCP port of the remote agent’s listening socket (default 5400) and choose the appropriate Group:
You can choose different values of TCP port for different servers according to your network configuration. But note that this value must match the parameter AGENT_PORT set in the agent’s configuration file (see details here).
After clicking “OK” you will see the server in the following list and you will be able to View, Edit and Delete the server (operations are marked with a red square).
After you have added all the desired servers and installed the remote agents the process of monitoring of your Linux hosts will start automatically.
https://www.nectus5.com/wp/wp-content/uploads/2018/02/logo.png00Web Masterhttps://www.nectus5.com/wp/wp-content/uploads/2018/02/logo.pngWeb Master2019-05-22 11:16:232019-05-22 11:16:23Configuring of Linux Monitoring in Nectus
Device View is the logical grouping of the devices that can be used in different places within the Nectus application. In the previous versions of Nectus, the user would manually add devices into device views which may become a significant management overhead.
In Nectus version 1.55 we introduced an ability to automatically populate device views based on specific conditions such as device names, types, etc.
User can define a set of conditions which has to be true for Nectus to automatically add devices to device views.
This article will guide you through the process of defining the auto population rules for device views.
To access your SNMP Device Views go to InventoryViewsSNMP Device View
To add a new Device View, click Create in the upper right hand corner of the SNMP Devices Views page.
Give a name to your new Device View.
.
Press Save button to finish creation of Device view.
Open again newly created device view and in the upper right-hand corner, select Edit Rules.
This will open the Devices View Auto Population Rules page.
Select the plus sign to add a new Auto Population Rule.
Add all the required Auto-population rules and press Ok button to Save.
If multiple rules are defined all the rules must be TRUE for device to be automatically added. (Logical AND).
Your rules will be processed daily at 3:00 PM.
If you would like to apply your rules immediately, press the Apply Rules button.
https://www.nectus5.com/wp/wp-content/uploads/2018/02/logo.png00Web Masterhttps://www.nectus5.com/wp/wp-content/uploads/2018/02/logo.pngWeb Master2019-05-15 20:33:012019-05-15 20:33:19Device View Auto Population Rules
Nectus Linux Monitoring Agent is required to be installed on target machine to enable Nectus to monitor Linux system parameters such as CPU and RAM utilization, Storage and Network Utilization.
Agent collects all the required monitoring metrics and reports to the main Nectus Server every 5 minutes.
Step 1: Download Monitoring Agent Package
Download binary package appropriate to your target machine Linux flavor and version from the download page.
Step 2a: Installation for Debian-based systems (including Ubuntu)
After downloading the package run the following installation command:
$ sudo dpkg -i <package-name>
This will install Nectus monitoring agent on your target machine. If everything is OK you’ll see some output like this:
$ sudo dpkg -i nectus-agent-1.0-1.deb
(Reading database … 79643 files and directories currently installed.)
Preparing to unpack nectus-agent-1.0-1.deb …
Unpacking nectus-agent (1.0-1) over (1.0-1) …
Setting up nectus-agent (1.0-1) …
Processing triggers for systemd (229-4ubuntu21.21) …
Processing triggers for ureadahead (0.100.0-19) …
Step 2b: Installation for RedHat and CentOS
After downloading the package run the following installation command:
$ sudo rpm -U <package-name>.rpm
You’ll see output like this:
$ sudo rpm -U nectus-agent-1.0-1.el7.x86_64.rpm
Preparing…
################################# [100%]
Updating / installing…
1:nectus-agent-1.0-1.el7
################################# [100%]
Step 3: Configuration
After installation is complete you need to set up the agent’s basic configuration.
Nectus agent configuration file is located at: /etc/nectus/nectus-agent.conf.
Default configuration file content is listed in Appendix 1. Most of the values are set to defaults and don’t require a change except following two parameters:
SERVER_PRESHARED_KEY
AGENT_PORT
SERVER_PRESHARED_KEY is used to encrypt messages between the Agent and Nectus Server. Initially it’s set to value <YourSecretKey>.
Edit this parameter to match the key configured in Nectus GUI (Settings->General Settings ->Linux Monitoring Integration).
SERVER_PRESHARED_KEY is a global parameters that is used for all Linux Servers.
AGENT_PORT parameter determines the TCP port used by Agent to listen for incoming connections from the Nectus server. By default the TCP port is set to 5400.
AGENT_PORT is Server specific parameter that can be different on each Linux Server.
Step 4: Generate SSL Certificate
The Linux Monitoring Agent listens on pre-configured TCP port for incoming HTTPS connection and needs an SSL certificate to operate.
Default location for storing certificate files is /etc/nectus but it’s configurable (parameter SSL_CERTIFICATE_DIR in the configuration file).
The Nectus agent is shipped with initial self-signed certificate which allows the module to process but it’s strongly recommended to replace this certificate.
You can either use some existing certificate or generate a new self-signed one.
To generate new self-signed certificate run commands:
The directory pointed by SSL_CERTIFICATE_DIR parameter should finally contain files dh.pem, key.pem and certificate.pem.
Step 5: Open TCP port at the Firewall
If there is firewall between Nectus Server and Linux Monitoring Agent you need to permit connections on TCP port 5400 (Unless it is changed to a different port)
Make sure your Linux internal firewall also permits inbound connections on this port.
Step 6: Start Agent
Restart the agent in order for configuration changes to take effect:
$ service nectus-agent restart
Check it’s status to ensure proper operation:
$ service nectus-agent status
If case of successful start you’ll see some output like this:
Apr 29 17:55:39 ubuntu-16 systemd[1]: Started Nectus Agent.
User account
For security reasons it’s not allowed to run Monitoring Agent as root user. If it’s trying to start as ‘root’ then the agent will drop its privileges to the user account set in configuration file
(usually /etc/nectus/nectus-agent.conf) as USER_INSTEAD_OF_ROOT.
Default USER_INSTEAD_OF_ROOT is ‘nectus’.
The agent automatically creates this user account during installation (if this user does not exist already) and provides minimal set of permissions required to run the agent code.
Troubleshooting
Nectus agent runs as a daemon process. You can use the following commands to start, stop restart and check status of the agent:
$ service nectus-agent start
$ service nectus-agent stop
$ service nectus-agent restart
$ service nectus-agent status
If there are any problems with starting the agent first check the agent’s status:
$ service nectus-agent status
Then check the log file (usually /var/log/nectus/nectus-agent.log). If it does not help then you can try to run the agent manually. Usage of the module:
nectus-agent <config-file> [-D]
config-file full path to configuration file
-D debug mode (agent starts not as a daemon but as a usual process)
Locate the executable nectus-agent in /usr/bin and try to run the agent not as a daemon:
ClickHouse Database Installation for Nectus Netflow & Syslog Storage
Requirements: Ubuntu Server 18.04.2 LTS (with SSH access)
NOTE: Although ClickHouse can be installed on several different flavors of Linux, Ubuntu Server 16.04 & 18.04 are the only supported Linux distributions for Nectus at this point.
NOTE: It is recommended to import the public key if it’s a fresh Ubuntu install.
Otherwise you may get the following error when adding the repository:GPG error: http://repo.yandex.ru/clickhouse/deb/stable main/ Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY C8F1E19FE0C56BD4
Now that we have installed the ClickHouse, it is time to test:
NOTE: TCP ports 8123 & 9000 must be open.
Start the Client:
clickhouse-client
Step 7
Create the Netflow/Syslog database.
In this example we are creating the netflow database named NETFLOW (database name is arbitrary):
clickhouse-client
create database NETFLOW
Step 8
We will now add the Clickhouse internal user “root” with password “nectus” to the Users.xml file located at: /etc/clickhouse-server/users.xml
NOTE: Paste the snippet of the code below starting at line 31 after “<users>” in the users.xml file. You can use vi or nano text editor to edit the file. WinSCP can also be used to accomplish this task. Use the file change owner command if needed “sudo chown -R xxxx users.xml”, where “xxxx” is the user that will take over the ownership of the file.
<root>
<password>nectus</password>
<networks incl=”networks” replace=”replace”>
<ip>::/0</ip>
</networks>
<profile>default</profile>
<quota>default</quota>
</root>
Save the file and exit.
Step 9
Restart the ClickHouse Server:
clickhouse-server restart
Step 10
Now that the ClickHouse Server has been restarted, we can start the ClickHouse client using the internal user that we created in step 8:
clickhouse-client –user default –password nectus
Step 11
We have completed the ClickHouse installation. This last step requires login to Nectus to finish the Netflow/Syslog integration.
Open to “Nectus Settings -> General Settings -> Netflow Integration” page
Enter the required information and click Test DB Connection (Remote Server IP is the IP address of the Ubuntu/ClickHouse server). The result should be “Test DB Connection OK”
Nectus 1.2.53 introduces ability to automatically discover and monitor iBGP and eBGP sessions across all router types and manufacturers.
Nectus scheduled network discovery automatically finds all the BGP sessions via SNMP polls and adds it to Nectus database where user can group them by type and enable active monitoring and alerting.
BGP Session Discovery
As part of regular scheduled network discovery Nectus detects all existing BGP Sessions and adds it to one of the existing BGP group which has “Default” flag set to ON.
You can see all the BGP sessions that were discovered in Inventory -> BGP Sessions or in left side panel called “BGP Sessions”
If you right-click on BGP Session and select “Properties”
.. you can assign a human friendly name or change a group membership for any of the BGP sessions.
You can create multiple BGP session groups and assign discovered BGP sessions to different groups according to its type or functional purpose.
To create a new Group, right-click on “BGP Sessions” line and select “Add New Group” on context menu.
Configure New Group name, set “Enable monitoring” to ON if you want all BGP Sessions in this group to be monitored for UP/DOWN Status.
If you set “Default” value to ON, this group will become a group where all newly discovered BGP sessions be added automatically. Only one group can have “Default” value set to ON
You can also assign BGP Session to a Group by right-clicking on BGP session and selecting “Move BGP Session to..” option
By clicking “View Session Info” on BGP Session context menu you can view detailed information about BGP Session
After you finished creating BGP session groups, assigning BGP sessions to corresponding groups and enabling BGP session groups for Monitoring the final step is to enable BGP Sessions monitoring in corresponding SNMP Device Monitoring Profiles that are applied to the routers that terminate all the BGP sessions.
https://www.nectus5.com/wp/wp-content/uploads/2018/02/logo.png00Web Masterhttps://www.nectus5.com/wp/wp-content/uploads/2018/02/logo.pngWeb Master2019-04-11 14:47:362019-04-11 14:47:36Features coming up in next Nectus release
https://www.nectus5.com/wp/wp-content/uploads/2018/02/logo.png00Web Masterhttps://www.nectus5.com/wp/wp-content/uploads/2018/02/logo.pngWeb Master2019-04-09 22:56:462019-04-10 07:37:45UPS Health Status Monitoring with Nectus
Suppression of Frequent Identical Alerts In Nectus
Often when a network device or interface changes its state between Up and Down multiple times in a short time interval, numerous identical alerts will be sent to all the configured alert recipients.
Nectus offers the ability to suppress frequent identical alerts to reduce informational noise level by specifying a suppression timer for up to three hours.
Nectus calculates a CRC hash value from each of the email alert bodies and if hash values of two alerts are matching they are considered to be identical and can be suppressed.
Nectus excludes event timer values and specific metric values from hash calculation logic. You can configure the suppression timer from 0 to 180 minutes where 0 means no suppression.
To configure the suppression timer, go to Monitoring -> Global Monitoring Settings
Under Monitoring Settings, select the Alerts tab.
To enable suppression specify a time interval from 1 to 180 minutes.
At the end of the time interval, alert logic will resume as normal.
To import a list of Windows Servers from CSV file to Nectus prepare a CSV file with only single column containing list of IP addresses of Windows Servers.
No other information is required.
File format example in Excel.
To start import, right-click on WMI Server Group that you want to import servers into and select “Import WMI Servers from CSV file” option
Select CSV File that you prepared.
Press “Start” button
Nectus will import each server individually and collect basic Server information via WMI Interface.
Adjusting Min. detectable ICMP outage duration in Nectus
When Nectus is configured to monitor UP/DOWN Status for network devices with ICMP it sends Echo packets at preset interval called Inter-Packet Delay.
By default, this Interval is set to 10 seconds.
Network Device is considered down if Echo-Reply is not received for “N” consecutive Echo packets.
By default “N” is set to 10.
So, by combining Inter-Packet Delay and “N” Value we can see that minimum duration of the outage that can be detected by Nectus with default settings is 100 seconds.
Sometimes when network a prone to fast transient outages or burstable traffic patterns that can impact ICMP it may be beneficial to increase minimum detectable ICMP outage duration to higher value. This can helps to eliminate alerts about short lived outages and only alert on outages that have more lasting impact.
To adjust Inter-Packet Delay or “N” Value go to “Monitoring -> Global Monitoring Settings”
And adjust values on “ICMP Monitoring” Tab according to your business needs.
Very often during site level power or network outages or during network maintenance multiple devices become offline at the same time causing multiple individual DOWN Email alerts to be sent at the same time.
Depending in the size of the site it can be well over hundreds or even thousands alert emails to be sent out to corresponding e-mail recipients configured for given site.
Starting from version 1.2.52 Nectus offers an option to aggregate multiple DOWN or UP email alerts into a single multi-device alert notification containing a list of all devices that became DOWN or UP within last monitoring interval.
To enable Alert Aggregation, go to Monitoring -> Global Monitoring Settings: “Alert” Tab
And Select “Aggregate multiple UP/DOWN Alerts” Option.
Very first step before you can start monitoring power supply status is to determine which SNMP OID is supported by specific router or switch type you want to monitor.
The main challenge here is that there is no consensus among manufacturers on specific SNMP OID and even within Cisco products OID can be different on different product lines.
Let’s take Cisco Catalyst 3750 series switches as an example.
For all Cisco 3700 series switches SNMP OID that contain power supply status is .1.3.6.1.4.1.9.9.13.1.5.1.3 (ciscoEnvMonSupplyState) from CISCO-ENVMON-MIB
Cisco TAC is usually a good resource to confirm which OID can be used for different Cisco product lines.
Step 2. Obtain Power Supply Index Values
Next step is to perform SNMP GET BULK or SNMP Walk query for selected OID (.1.3.6.1.4.1.9.9.13.1.5.1.3) against one of the switches that you planning to monitor to determine how many power supplies this specific switch model has and what are the index values for each power supply.
Sample GET Bulk Response from Cisco Catalyst 3750:
‘1.3.6.1.4.1.9.9.13.1.5.1.3.[1034]’ => “1”
‘1.3.6.1.4.1.9.9.13.1.5.1.3.[2034]’ => “1”
In this SNMP GET-BULK response we see that switch has two power supplies with indexes: 1034 and 2034.
Step 3. Obtain list of Status Values for SNMP OID
Last step before we can start monitoring power supply is to consult MIB for possible values that this specific OID can report for power supply status.
For SNMP OID 1.3.6.1.4.1.9.9.13.1.5.1.3 there are 6 possible status codes:
Normal (1), Warning (2), Critical (3), Shutdown (4), Not Present (5), Not Functioning (6)
Step 4. Create Custom SNMP Tracker for Each Power Supply
Now we are ready to create custom SNMP trackers for each of the power supplies.
In Nectus GUI go to Monitoring → SNMP Monitoring Settings → Custom SNMP Trackers
Press “Create” button to bring up Custom SNMP Tracer creation interface.
We will have to create two separate trackers, one for each power supply.
Complete tracker “General” settings Tab according to this
Note that for this tracker we created a device view called “Cisco Catalyst 3700 Switches” that contain all Cisco Catalyst 3700 Series switches that we want to monitor with this tracker.
If you want to enable Power supply monitoring for more switches later, you just need to add new switches to this Device View.
Select which email lists will be used as email Alert recipients.
In “Alerts” Tab we need to specify which status values will be considered Normal and which values should trigger Alerts. You can specify multiple values separated by comma.
Define an Alert Severity level for Alarm Values as Informational, Warning or Critical.
Define number of consecutive readings for which power supply status has to report an Alarm condition before formal Alert is created. Nectus performs one SNMP poll per 5 min.
So if you define value for consecutive readings as 3 it should result in Alert created after 15 minutes of True Alarm conditions.
Press “Save” to complete Custom SNMP tracker creation for Power Supply 1.
Repeat the same process for Power Supply 2.
Now you have created custom trackers that will be monitoring both power supplies on all Cisco Catalyst 3700 Switches in your network.
https://www.nectus5.com/wp/wp-content/uploads/2018/02/logo.png00Web Masterhttps://www.nectus5.com/wp/wp-content/uploads/2018/02/logo.pngWeb Master2019-03-21 19:32:142019-03-21 20:17:41Monitoring Cisco Power Supplies with SNMP
One of the unique features offered by Nectus is the ability to logically split each subnet into predefined ranges reserved for specific categories such as users, servers, infrastructure devices, etc. This is done with the help of subnet profiles. In Nectus, subnet profile is a set of IP ranges with a unique color code and a distinct name. Color coding makes it easier to locate an IP range reserved for a specific device type. This article explains how to create subnet profiles in Nectus.
Creating a Subnet Profile
To create a new subnet profile, go to Main Menu and select Settings → General Settings → IPAM Integration.
In the “IPAM Integration” window that appears, select Subnet Profile tab and click Add button.
Begin defining a new subnet profile in the “Add Subnet Profile” GUI window that appears. Assign a name to your new profile. Define the first device category. Determine how many IP address you would like to reserve for the first device category and assign an order number for the first (Start) and the last (End) IP address in the group. Chose a color code for the device category.
Use + button to add additional device categories. Press Save to save your new profile.
2. Assigning Profile to a Subnet
To assign a profile to a subnet, right click on the selected subnet and select Properties.
On the “Properties” page that appears, select the desired profile and press Save button.
3. Benefits of Subnet Profiles
Once you have assigned a profile to a subnet, your subnet map will display color-coded IP ranges reserved for the device categories.
This visual guide will help you better manage IP addresses in the subnet.
When importing Subnets into IPAM from routing protocols Nectus apply following rules:
Only subnets from IGRP routing protocols (EIGRP, OSPF, ISIS, RIP) are being considered for import.
Nectus will not import subnets from iBGP or eBGP.
Nectus start importing subnets in the order from smallest to largest: /32 , /31, then /30, then /29…etc. This is done to give individual subnets priority over summaries.
Every imported subnet is validated against overlapping with existing subnets.
Nectus will not import subnets that overlap with any of the existing subnets.
Nectus will only import subnets that fall into defined IPAM address space.
One of the unique features of Nectus IPAM is ability to define unlimited number of properties aka “custom tags” and assign it to any of the subnets.
For example: “Building Floor”, “Datacenter” or “Application Name” can be defined for each subnet as a custom Tag.
To create a new custom tag go to Settings → General Setting → IPAM Integration
On “Subnet Tags” tab you will see current list of Tags that already exist in database.
To add a new tag press “+” button next to drop-down menu with all the tags.
Specify Tag name and press “Save” button
After you defined Tag’s name you can start adding specific Tag values for this Tag by pressing on “+ Add” button at the right upper corner of the page.
You can define as many Tag Value as required.
After you finished defining Tag values you can open Properties for any subnet in IPAM and you will see all the defined Tags as a drop-down menus where you can select specific Tag value for given subnet.
Nectus IPAM offers extensive DHCP integration features with one of the most important is ability to create and manage DHCP Scopes split across multiple DHCP Servers.
To create a new DHCP Split-Scope go to “Inventory → IPAM Subnets and Reservations”
Select “IPv4 DHCP Subnets” Tab and press “Add Subnets” button.
Specify basic Subnet info and select the DHCP Servers that will be serving IP addresses for this subnet. Define “Start” and “End” IP address for each selected DHCP Server.
In this example subnet 10.20.20.0/24 is split across two DHCP servers: PLUTO and NEON.
Server PLUTO is serving IP addresses from range: 10.20.20.1-10.20.20.200
Server NEON is serving IP addresses from range: 10.20.20.201-10.20.20.254
Always make sure that split-scope ranges don’t overlap to prevent duplicate IPs being leased.
Standalone NetFlow and Syslog VM OVA File (Clickhouse DB)
NetFlow IPFIX CFlow SFlow, Syslog, Technical NotesConfiguring of Linux Monitoring in Nectus
Linux Monitoring, Technical NotesConfiguring of Linux Monitoring in Nectus
Nectus Server 1.55 adds feature to monitor some system parameters on hosts running Linux. Enabling this feature for your infrastructure requires two steps:
This guide describes steps for Nectus Server configs. Installing and configuring of Linux remote agents are described here.
Linux monitoring integration
Choose the following menu item from the Nectus GUI to set global Linux monitoring parameters.
This will open the next window:
Click OK to save configured parameters.
Select “Linux Monitoring Settings” from the “Monitoring” menu to configure your monitoring profiles for Linux machines.
Click “Create” to create a new monitoring profile:
In the following form enter the name of your profile and choose metrics you would like to monitor:
Configure the necessary metric parameters like minimal and maximal thresholds, alerting etc.
You can create any number of profiles and assign each of them to different group of Linux machines.
Linux Servers
Select “Linux Servers” from the “Inventory” menu to configure groups and servers to be monitored.
Click “Create new Group” in the next form:
Enter “Group Name” for the new group, select “Enable monitoring” and choose the desired Monitoring Profile for this server group:
Also select the appropriate alert recipients in this form.
You can create any number of monitoring groups if you need to apply different profiles or alert recipients for different server groups.
When you have finished with the groups switch to the next tab “Servers” in the same form and click “Add Server” to add a Linux server to be monitored:
In the next window enter the Hostname (optional, it will be obtained later during the monitoring process), IP address, TCP port of the remote agent’s listening socket (default 5400) and choose the appropriate Group:
You can choose different values of TCP port for different servers according to your network configuration. But note that this value must match the parameter AGENT_PORT set in the agent’s configuration file (see details here).
After clicking “OK” you will see the server in the following list and you will be able to View, Edit and Delete the server (operations are marked with a red square).
After you have added all the desired servers and installed the remote agents the process of monitoring of your Linux hosts will start automatically.
Device View Auto Population Rules
Nectus Installation, Network Monitoring, Technical NotesDevice View Auto Population Rules
Device View is the logical grouping of the devices that can be used in different places within the Nectus application. In the previous versions of Nectus, the user would manually add devices into device views which may become a significant management overhead.
In Nectus version 1.55 we introduced an ability to automatically populate device views based on specific conditions such as device names, types, etc.
User can define a set of conditions which has to be true for Nectus to automatically add devices to device views.
This article will guide you through the process of defining the auto population rules for device views.
To access your SNMP Device Views go to Inventory Views SNMP Device View
To add a new Device View, click Create in the upper right hand corner of the SNMP Devices Views page.
Give a name to your new Device View.
Press Save button to finish creation of Device view.
Open again newly created device view and in the upper right-hand corner, select Edit Rules.
This will open the Devices View Auto Population Rules page.
Select the plus sign to add a new Auto Population Rule.
Add all the required Auto-population rules and press Ok button to Save.
If multiple rules are defined all the rules must be TRUE for device to be automatically added. (Logical AND).
Your rules will be processed daily at 3:00 PM.
If you would like to apply your rules immediately, press the Apply Rules button.
Linux Monitoring Agent Installation
Linux MonitoringLinux Monitoring Agent Installation
Nectus Linux Monitoring Agent is required to be installed on target machine to enable Nectus to monitor Linux system parameters such as CPU and RAM utilization, Storage and Network Utilization.
Agent collects all the required monitoring metrics and reports to the main Nectus Server every 5 minutes.
Step 1: Download Monitoring Agent Package
Download binary package appropriate to your target machine Linux flavor and version from the download page.
Step 2a: Installation for Debian-based systems (including Ubuntu)
After downloading the package run the following installation command:
$ sudo dpkg -i <package-name>
This will install Nectus monitoring agent on your target machine. If everything is OK you’ll see some output like this:
$ sudo dpkg -i nectus-agent-1.0-1.deb
(Reading database … 79643 files and directories currently installed.)
Preparing to unpack nectus-agent-1.0-1.deb …
Unpacking nectus-agent (1.0-1) over (1.0-1) …
Setting up nectus-agent (1.0-1) …
Processing triggers for systemd (229-4ubuntu21.21) …
Processing triggers for ureadahead (0.100.0-19) …
Step 2b: Installation for RedHat and CentOS
After downloading the package run the following installation command:
$ sudo rpm -U <package-name>.rpm
You’ll see output like this:
$ sudo rpm -U nectus-agent-1.0-1.el7.x86_64.rpm
Preparing…
################################# [100%]
Updating / installing…
1:nectus-agent-1.0-1.el7
################################# [100%]
Step 3: Configuration
After installation is complete you need to set up the agent’s basic configuration.
Nectus agent configuration file is located at: /etc/nectus/nectus-agent.conf.
Default configuration file content is listed in Appendix 1. Most of the values are set to defaults and don’t require a change except following two parameters:
SERVER_PRESHARED_KEY is used to encrypt messages between the Agent and Nectus Server. Initially it’s set to value <YourSecretKey>.
Edit this parameter to match the key configured in Nectus GUI (Settings->General Settings ->Linux Monitoring Integration).
SERVER_PRESHARED_KEY is a global parameters that is used for all Linux Servers.
AGENT_PORT parameter determines the TCP port used by Agent to listen for incoming connections from the Nectus server. By default the TCP port is set to 5400.
AGENT_PORT is Server specific parameter that can be different on each Linux Server.
Step 4: Generate SSL Certificate
The Linux Monitoring Agent listens on pre-configured TCP port for incoming HTTPS connection and needs an SSL certificate to operate.
Default location for storing certificate files is /etc/nectus but it’s configurable (parameter SSL_CERTIFICATE_DIR in the configuration file).
The Nectus agent is shipped with initial self-signed certificate which allows the module to process but it’s strongly recommended to replace this certificate.
You can either use some existing certificate or generate a new self-signed one.
To generate new self-signed certificate run commands:
$ cd /etc/nectus
$ openssl dhparam -out dh.pem 1024
$ openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 10000 -out certificate.pem
The directory pointed by SSL_CERTIFICATE_DIR parameter should finally contain files dh.pem, key.pem and certificate.pem.
Step 5: Open TCP port at the Firewall
If there is firewall between Nectus Server and Linux Monitoring Agent you need to permit connections on TCP port 5400 (Unless it is changed to a different port)
Make sure your Linux internal firewall also permits inbound connections on this port.
Step 6: Start Agent
Restart the agent in order for configuration changes to take effect:
$ service nectus-agent restart
Check it’s status to ensure proper operation:
$ service nectus-agent status
If case of successful start you’ll see some output like this:
$ service nectus-agent status
● nectus-agent.service – Nectus Agent
Loaded: loaded (/lib/systemd/system/nectus-agent.service; disabled; vendor preset: enabled)
Active: active (running) since Mon 2019-04-29 17:55:39 UTC; 4s ago
Process: 10247 ExecStart=/usr/bin/nectus-agent $CONFFILE (code=exited, status=0/SUCCESS)
Main PID: 10255 (nectus-agent)
Tasks: 2
Memory: 1.2M
CPU: 14ms
CGroup: /system.slice/nectus-agent.service
└─10255 /usr/bin/nectus-agent /etc/nectus/nectus-agent.conf
Apr 29 17:55:39 ubuntu-16 systemd[1]: Starting Nectus Agent…
Apr 29 17:55:39 ubuntu-16 systemd[1]: nectus-agent.service: PID file /run/nectus/nectus-agent.pid not readable
Apr 29 17:55:39 ubuntu-16 systemd[1]: Started Nectus Agent.
User account
For security reasons it’s not allowed to run Monitoring Agent as root user. If it’s trying to start as ‘root’ then the agent will drop its privileges to the user account set in configuration file
(usually /etc/nectus/nectus-agent.conf) as USER_INSTEAD_OF_ROOT.
Default USER_INSTEAD_OF_ROOT is ‘nectus’.
The agent automatically creates this user account during installation (if this user does not exist already) and provides minimal set of permissions required to run the agent code.
Troubleshooting
Nectus agent runs as a daemon process. You can use the following commands to start, stop restart and check status of the agent:
$ service nectus-agent start
$ service nectus-agent stop
$ service nectus-agent restart
$ service nectus-agent status
If there are any problems with starting the agent first check the agent’s status:
$ service nectus-agent status
Then check the log file (usually /var/log/nectus/nectus-agent.log). If it does not help then you can try to run the agent manually. Usage of the module:
nectus-agent <config-file> [-D]
config-file full path to configuration file
-D debug mode (agent starts not as a daemon but as a usual process)
Locate the executable nectus-agent in /usr/bin and try to run the agent not as a daemon:
$ /usr/bin/nectus-agent /etc/nectus/nectus-agent.conf -D
Check the output and log files at /var/log/nectus.
Upgrade
Upgrade to a new version of the agent is the same as a new installation: download the appropriate package and run either:
> sudo dpkg -i <package-name>.deb
for Debian/Ubuntu systems or
> sudo rpm -U <package-name>.rpm
for RedHat/CentOS.
Uninstallation
To uninstall Nectus agent run the following command:
> sudo dpkg -r nectus-agent
for Debian/Ubuntu systems or
> sudo rpm -e nectus-agent
for RedHat/CentOS.
Appendix 1. Default Configuration File
ClickHouse DB Installation for Nectus Netflow & Syslog Storage
Nectus Installation, NetFlow IPFIX CFlow SFlow, SyslogClickHouse Database Installation for Nectus Netflow & Syslog Storage
Requirements: Ubuntu Server 18.04.2 LTS (with SSH access)
NOTE: Although ClickHouse can be installed on several different flavors of Linux, Ubuntu Server 16.04 & 18.04 are the only supported Linux distributions for Nectus at this point.
More information about installation on other OS’s can be found here: https://clickhouse.yandex/docs/en/getting_started/
Step 1
Import the public key:
apt-get update
sudo apt-key adv –keyserver keyserver.ubuntu.com –recv C8F1E19FE0C56BD4
NOTE: It is recommended to import the public key if it’s a fresh Ubuntu install.
Otherwise you may get the following error when adding the repository:GPG error: http://repo.yandex.ru/clickhouse/deb/stable main/ Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY C8F1E19FE0C56BD4
Optional commands to run:
sudo apt-key adv –keyserver keyserver.ubuntu.com –recv E0C56BD4
Step 2
Create Clickhouse repository:
sudo apt-get install dirmngr
sudo apt-add-repository “deb http://repo.yandex.ru/clickhouse/deb/stable/ main/”
NOTE: Please edit the sources.list file if you receive the following error:
“E: Mailformed entry 55 in list file /etc/apt/sources.list”.
Delete the entry XX and save/exit the file. Perform the update (and upgrade if you wish):
sudo apt-get update
Step 3
Get the packages list for the latest updates and the dependencies:
apt-get update && apt-get upgrade
Step 4
Download and Install the ClickHouse packages:
sudo apt-get install -y clickhouse-server clickhouse-server-common clickhouse-client
sudo apt-get install –allow-unauthenticated clickhouse-server-common clickhouse-client clickhouse-server
Step 5
Start the Clickhouse server as a daemon:
sudo service clickhouse-server start
Step 6
Now that we have installed the ClickHouse, it is time to test:
NOTE: TCP ports 8123 & 9000 must be open.
Start the Client:
clickhouse-client
Step 7
Create the Netflow/Syslog database.
In this example we are creating the netflow database named NETFLOW (database name is arbitrary):
clickhouse-client
create database NETFLOW
Step 8
We will now add the Clickhouse internal user “root” with password “nectus” to the Users.xml file located at: /etc/clickhouse-server/users.xml
NOTE: Paste the snippet of the code below starting at line 31 after “<users>” in the users.xml file. You can use vi or nano text editor to edit the file. WinSCP can also be used to accomplish this task. Use the file change owner command if needed “sudo chown -R xxxx users.xml”, where “xxxx” is the user that will take over the ownership of the file.
<root>
<password>nectus</password>
<networks incl=”networks” replace=”replace”>
<ip>::/0</ip>
</networks>
<profile>default</profile>
<quota>default</quota>
</root>
Save the file and exit.
Step 9
Restart the ClickHouse Server:
clickhouse-server restart
Step 10
Now that the ClickHouse Server has been restarted, we can start the ClickHouse client using the internal user that we created in step 8:
clickhouse-client –user default –password nectus
Step 11
We have completed the ClickHouse installation. This last step requires login to Nectus to finish the Netflow/Syslog integration.
Open to “Nectus Settings -> General Settings -> Netflow Integration” page
Enter the required information and click Test DB Connection (Remote Server IP is the IP address of the Ubuntu/ClickHouse server). The result should be “Test DB Connection OK”
Click “Run Integration Scripts” and finally Save.
Step 12
Restart Nectus NetFlow and Syslog Services.
Monitoring BGP Sessions with Nectus
Network Monitoring, Technical NotesMonitoring BGP Sessions with Nectus
Nectus 1.2.53 introduces ability to automatically discover and monitor iBGP and eBGP sessions across all router types and manufacturers.
Nectus scheduled network discovery automatically finds all the BGP sessions via SNMP polls and adds it to Nectus database where user can group them by type and enable active monitoring and alerting.
BGP Session Discovery
As part of regular scheduled network discovery Nectus detects all existing BGP Sessions and adds it to one of the existing BGP group which has “Default” flag set to ON.
You can see all the BGP sessions that were discovered in Inventory -> BGP Sessions or in left side panel called “BGP Sessions”
If you right-click on BGP Session and select “Properties”
.. you can assign a human friendly name or change a group membership for any of the BGP sessions.
You can create multiple BGP session groups and assign discovered BGP sessions to different groups according to its type or functional purpose.
To create a new Group, right-click on “BGP Sessions” line and select “Add New Group” on context menu.
Configure New Group name, set “Enable monitoring” to ON if you want all BGP Sessions in this group to be monitored for UP/DOWN Status.
If you set “Default” value to ON, this group will become a group where all newly discovered BGP sessions be added automatically. Only one group can have “Default” value set to ON
You can also assign BGP Session to a Group by right-clicking on BGP session and selecting “Move BGP Session to..” option
By clicking “View Session Info” on BGP Session context menu you can view detailed information about BGP Session
After you finished creating BGP session groups, assigning BGP sessions to corresponding groups and enabling BGP session groups for Monitoring the final step is to enable BGP Sessions monitoring in corresponding SNMP Device Monitoring Profiles that are applied to the routers that terminate all the BGP sessions.
Find required SNMP Monitoring Profile and enable “BGP Session Status” Monitoring Option
Now are you all set to start monitoring your BGP sessions line a pro.
Features coming up in next Nectus release
Nectus NewsUPS Health Status Monitoring with Nectus
Network Monitoring, Technical NotesUPS Status Monitoring with Nectus
Health monitoring of UPS units is one of the most critical tasks of network infrastructure monitoring.
If UPS fails during power outage it results in immediate network downtime resulting in loss of revenue and degrading user experience.
Most of the modern UPS Units perform daily self-tests and results of those self-tests are available via SNMP protocol.
Our goal is to collect those self-test results on regular basis and generate an alert or incident when self-test indicates a UPS failure.
Step 1. Determine which SNMP OID to use
Very first step before you can start monitoring UPS health status is to determine which SNMP OID contains self-test information for your UPS units.
You can open a support case with your UPS vendor and request SNNP OID string for self-test information.
For example, SNMP OID for self-test information from UPS manufactured by APC is .1.3.6.1.4.1.318.1.1.1.7.2.3.0
This OID returns following values:
1 = Ok
2 = Failed
3 = Invalid Test
4 = Test In Progress
Step 2. Create Device View that contain all UPS units
Next step is to create a Device View that contain all UPS units that we want to monitor.
To create a Device View go to Inventory -> Views -> SNMP Device Views.
Create a new Device Vice called “UPS Units”
Step 3. Create Custom SNMP Tracker for UPS Self-Test Info
Now we are ready to create a custom SNMP tracker that will be polling our UPS units every 5 min for self-test information.
In Nectus GUI go to Monitoring → SNMP Monitoring Settings → Custom SNMP Trackers
Press “Create” button to bring up Custom SNMP Tracker creation interface.
Complete tracker General information tab with correct SNMP OID and select Device View that contains all UPS units that we want to monitor.
Select Email and SMS list for Alert Recipients.
In “Alerts” Tab we need to specify which status values will be considered Normal and which values should trigger Alerts.
You can specify multiple values separated by comma.
Define an Alert Severity level for Alarm Values as Informational, Warning or Critical.
Define number of consecutive readings for which UPS self-test status must report an Alarm condition before formal Alert is created.
Nectus performs one SNMP poll per 5 min.
If you define value for consecutive readings as 3 it should result in Alert created after 15 minutes of True Alarm conditions.
Press “Save” to complete Custom SNMP tracker creation for UPS Status Monitoring
This completes creation of custom tracker that will be monitoring UPS self-test information on all APC UPS units in your network.
Suppression of Frequent Identical Alerts In Nectus
Network Monitoring, Technical NotesSuppression of Frequent Identical Alerts In Nectus
Often when a network device or interface changes its state between Up and Down multiple times in a short time interval, numerous identical alerts will be sent to all the configured alert recipients.
Nectus offers the ability to suppress frequent identical alerts to reduce informational noise level by specifying a suppression timer for up to three hours.
Nectus calculates a CRC hash value from each of the email alert bodies and if hash values of two alerts are matching they are considered to be identical and can be suppressed.
Nectus excludes event timer values and specific metric values from hash calculation logic. You can configure the suppression timer from 0 to 180 minutes where 0 means no suppression.
To configure the suppression timer, go to Monitoring -> Global Monitoring Settings
Under Monitoring Settings, select the Alerts tab.
To enable suppression specify a time interval from 1 to 180 minutes.
At the end of the time interval, alert logic will resume as normal.
Setting timer to 0 will disable the suppression.
Importing WMI Servers from CSV file to Nectus
Technical Notes, Windows Server (WMI) MonitoringImporting WMI Servers from CSV file to Nectus
To import a list of Windows Servers from CSV file to Nectus prepare a CSV file with only single column containing list of IP addresses of Windows Servers.
No other information is required.
File format example in Excel.
To start import, right-click on WMI Server Group that you want to import servers into and select “Import WMI Servers from CSV file” option
Select CSV File that you prepared.
Press “Start” button
Nectus will import each server individually and collect basic Server information via WMI Interface.
Configuring WMI Integration in Nectus
Technical Notes, Uncategorized, Windows Server (WMI) MonitoringConfiguring WMI Integration in Nectus
Nectus uses WMI Interface in several of its modules.
List of modules that depends on WMI Integration:
In Windows Server Monitoring module Nectus uses WMI interface to poll Windows Servers for critical health metrics such as CPU and RAM Utilization etc.
In IPAM Module Nectus uses WMI interface to interact with Microsoft DNS and DHCP servers while Importing and creating reservations.
WMI Integration settings must be complete before Nectus can communicate with Windows Servers in those modules.
To complete WMI Integration go to Settings -> General Settings -> WMI Integration
Click on “WMI Integration” link and complete all the required fields for WMI Service account
that will be used by Nectus connect to Windows Servers via WMI Interface.
WMI Service account should not have password expiration policy to prevent Integration from breaking every time password has to be changed.
Use “Test” button to test Service account credential against any of Windows Servers of your choice.
After connection “Test” is passed WMI Integration is complete.
Adjusting min. detectable ICMP outage duration in Nectus
Network Monitoring, Technical NotesAdjusting Min. detectable ICMP outage duration in Nectus
When Nectus is configured to monitor UP/DOWN Status for network devices with ICMP it sends Echo packets at preset interval called Inter-Packet Delay.
By default, this Interval is set to 10 seconds.
Network Device is considered down if Echo-Reply is not received for “N” consecutive Echo packets.
By default “N” is set to 10.
So, by combining Inter-Packet Delay and “N” Value we can see that minimum duration of the outage that can be detected by Nectus with default settings is 100 seconds.
Sometimes when network a prone to fast transient outages or burstable traffic patterns that can impact ICMP it may be beneficial to increase minimum detectable ICMP outage duration to higher value. This can helps to eliminate alerts about short lived outages and only alert on outages that have more lasting impact.
To adjust Inter-Packet Delay or “N” Value go to “Monitoring -> Global Monitoring Settings”
And adjust values on “ICMP Monitoring” Tab according to your business needs.
Monitoring HTTP URLs with Nectus NMS
HTTP URL Moniitoring, Technical NotesMonitoring HTTP URLs with Nectus NMS
Have you ever been surprised to find out your website hadn’t been running or online?
Realtime status updates of your website can relieve you of the frustration of downtime and provide with instant alerts to your team.
Nectus HTTP Monitoring module can take the burden of URL monitoring away and provide real-time status of thousands of URLs, all using one quick view.
Nectus can poll websites on with preset frequency and alert you via Email or SMS if any of the websites are down.
Creating URL Groups in Nectus
HTTP URL Monitoring starts with creating URL Groups.
To create a URL group, right click on the Web Servers group on the left side panel. When the context menu appears, click on Add New Group.
After clicking Add New Group, a pop-up window appears.
Window allows you to set a Poll Frequency, which defined how often Nectus will poll your website.
Enable Monitoring can be checked to begin monitoring for all URLs that are members of this group.
Send Alerts to Email Group and Send Alerts to SMS Group can be checked to specify URL Down Alert recepients for Email or SMS notifications.
To modify members’ list of any of the existing E-mail or SMS groups click on the group name.
Once you click on the Alert group name a popup window appears where changes can be made to the existing alert groups.
Adding URLs to Groups in Nectus
After creating URL groups, you now may add URLs that you want to monitor to the group you have just created.
Right Click on any of the group name and select: Add New URL
After clicking Add New URL, you can add the URL and give the URL a specific name. You may also specify which group the URL goes into.
Once you have added the URL, monitoring start automatically.
Repeat this process for every URL you’d like to enable for monitoring.
After you have finished adding all of your URLs you will be able to quickly see the status of all the URLs in the left side panel.
Multiple Alert Email Aggregation in Nectus
Network Monitoring, Technical NotesMultiple Alert Email Aggregation in Nectus
Very often during site level power or network outages or during network maintenance multiple devices become offline at the same time causing multiple individual DOWN Email alerts to be sent at the same time.
Depending in the size of the site it can be well over hundreds or even thousands alert emails to be sent out to corresponding e-mail recipients configured for given site.
Starting from version 1.2.52 Nectus offers an option to aggregate multiple DOWN or UP email alerts into a single multi-device alert notification containing a list of all devices that became DOWN or UP within last monitoring interval.
To enable Alert Aggregation, go to Monitoring -> Global Monitoring Settings: “Alert” Tab
And Select “Aggregate multiple UP/DOWN Alerts” Option.
Monitoring Cisco Power Supplies with SNMP
Network Monitoring, Technical NotesMonitoring Cisco Power Supplies with SNMP
Cisco Power Supply
Step 1. Determine which SNMP OID to use
Very first step before you can start monitoring power supply status is to determine which SNMP OID is supported by specific router or switch type you want to monitor.
The main challenge here is that there is no consensus among manufacturers on specific SNMP OID and even within Cisco products OID can be different on different product lines.
Let’s take Cisco Catalyst 3750 series switches as an example.
For all Cisco 3700 series switches SNMP OID that contain power supply status is .1.3.6.1.4.1.9.9.13.1.5.1.3 (ciscoEnvMonSupplyState) from CISCO-ENVMON-MIB
Cisco TAC is usually a good resource to confirm which OID can be used for different Cisco product lines.
Step 2. Obtain Power Supply Index Values
Next step is to perform SNMP GET BULK or SNMP Walk query for selected OID (.1.3.6.1.4.1.9.9.13.1.5.1.3) against one of the switches that you planning to monitor to determine how many power supplies this specific switch model has and what are the index values for each power supply.
Sample GET Bulk Response from Cisco Catalyst 3750:
‘1.3.6.1.4.1.9.9.13.1.5.1.3.[1034]’ => “1”
‘1.3.6.1.4.1.9.9.13.1.5.1.3.[2034]’ => “1”
In this SNMP GET-BULK response we see that switch has two power supplies with indexes: 1034 and 2034.
Step 3. Obtain list of Status Values for SNMP OID
Last step before we can start monitoring power supply is to consult MIB for possible values that this specific OID can report for power supply status.
For SNMP OID 1.3.6.1.4.1.9.9.13.1.5.1.3 there are 6 possible status codes:
Normal (1), Warning (2), Critical (3), Shutdown (4), Not Present (5), Not Functioning (6)
Step 4. Create Custom SNMP Tracker for Each Power Supply
Now we are ready to create custom SNMP trackers for each of the power supplies.
In Nectus GUI go to Monitoring → SNMP Monitoring Settings → Custom SNMP Trackers
Press “Create” button to bring up Custom SNMP Tracer creation interface.
We will have to create two separate trackers, one for each power supply.
Complete tracker “General” settings Tab according to this
Note that for this tracker we created a device view called “Cisco Catalyst 3700 Switches” that contain all Cisco Catalyst 3700 Series switches that we want to monitor with this tracker.
If you want to enable Power supply monitoring for more switches later, you just need to add new switches to this Device View.
Select which email lists will be used as email Alert recipients.
In “Alerts” Tab we need to specify which status values will be considered Normal and which values should trigger Alerts. You can specify multiple values separated by comma.
Define an Alert Severity level for Alarm Values as Informational, Warning or Critical.
Define number of consecutive readings for which power supply status has to report an Alarm condition before formal Alert is created. Nectus performs one SNMP poll per 5 min.
So if you define value for consecutive readings as 3 it should result in Alert created after 15 minutes of True Alarm conditions.
Press “Save” to complete Custom SNMP tracker creation for Power Supply 1.
Repeat the same process for Power Supply 2.
Now you have created custom trackers that will be monitoring both power supplies on all Cisco Catalyst 3700 Switches in your network.
System Variables supported for IPv4 Monitors E-mail and SMS Alerts
Network Monitoring, Technical Notes%monitor_name%
%monitor_ipv4_address%
%metric_name%
%metric_value%
%unit_name%
Using Subnet Profiles in Nectus IPAM
IPAM (IP Address Management), Technical NotesUsing Subnet Profiles in Nectus IPAM
One of the unique features offered by Nectus is the ability to logically split each subnet into predefined ranges reserved for specific categories such as users, servers, infrastructure devices, etc. This is done with the help of subnet profiles. In Nectus, subnet profile is a set of IP ranges with a unique color code and a distinct name. Color coding makes it easier to locate an IP range reserved for a specific device type. This article explains how to create subnet profiles in Nectus.
To create a new subnet profile, go to Main Menu and select Settings → General Settings → IPAM Integration.
In the “IPAM Integration” window that appears, select Subnet Profile tab and click Add button.
Begin defining a new subnet profile in the “Add Subnet Profile” GUI window that appears. Assign a name to your new profile. Define the first device category. Determine how many IP address you would like to reserve for the first device category and assign an order number for the first (Start) and the last (End) IP address in the group. Chose a color code for the device category.
Use + button to add additional device categories. Press Save to save your new profile.
2. Assigning Profile to a Subnet
To assign a profile to a subnet, right click on the selected subnet and select Properties.
On the “Properties” page that appears, select the desired profile and press Save button.
3. Benefits of Subnet Profiles
Once you have assigned a profile to a subnet, your subnet map will display color-coded IP ranges reserved for the device categories.
This visual guide will help you better manage IP addresses in the subnet.
Importing subnets to IPAM from IGP routing protocols explained.
IPAM (IP Address Management), Technical NotesWhen importing Subnets into IPAM from routing protocols Nectus apply following rules:
Using Custom Subnet Tags in Nectus IPAM
IPAM (IP Address Management), Technical NotesUsing Custom Subnet Tags in Nectus IPAM
One of the unique features of Nectus IPAM is ability to define unlimited number of properties aka “custom tags” and assign it to any of the subnets.
For example: “Building Floor”, “Datacenter” or “Application Name” can be defined for each subnet as a custom Tag.
To create a new custom tag go to Settings → General Setting → IPAM Integration
On “Subnet Tags” tab you will see current list of Tags that already exist in database.
To add a new tag press “+” button next to drop-down menu with all the tags.
Specify Tag name and press “Save” button
After you defined Tag’s name you can start adding specific Tag values for this Tag by pressing on “+ Add” button at the right upper corner of the page.
You can define as many Tag Value as required.
After you finished defining Tag values you can open Properties for any subnet in IPAM and you will see all the defined Tags as a drop-down menus where you can select specific Tag value for given subnet.
Creating DHCP Split Scopes in Nectus IPAM
IPAM (IP Address Management)Creating DHCP Split Scopes in Nectus IPAM
Nectus IPAM offers extensive DHCP integration features with one of the most important is ability to create and manage DHCP Scopes split across multiple DHCP Servers.
To create a new DHCP Split-Scope go to “Inventory → IPAM Subnets and Reservations”
Select “IPv4 DHCP Subnets” Tab and press “Add Subnets” button.
Specify basic Subnet info and select the DHCP Servers that will be serving IP addresses for this subnet. Define “Start” and “End” IP address for each selected DHCP Server.
In this example subnet 10.20.20.0/24 is split across two DHCP servers: PLUTO and NEON.
Server PLUTO is serving IP addresses from range: 10.20.20.1-10.20.20.200
Server NEON is serving IP addresses from range: 10.20.20.201-10.20.20.254
Always make sure that split-scope ranges don’t overlap to prevent duplicate IPs being leased.