Monitoring Cisco IPSec VPN Tunnels with Nectus

,

Monitoring Cisco IPSec VPN Tunnels with Nectus

One of the key features introduced in Nectus 1.2.51 is ability to automatically discover and monitor Cisco IPSec VPN Tunnels terminated on ASA Firewalls and regular IOS routers.

  1. Tunnel Discovery

As part of regular scheduled network discovery Nectus attempts to detect existing VPN tunnels on all routers and firewalls by polling standard SNMP MIB: CISCO-IPSEC-FLOW-MONITOR-MIB

reserved for VPN Tunnels.

All discovered VPN tunnels can be seen in Main menu: Inventory → VPN Tunnels

 

 

All discovered tunnels displayed as a table with Terminating Device, Group, Local and Remote IP Address visible in individual columns.

You can assign a human friendly name to each tunnel by pressing Tunnel Edit button on the right.

 

  1. Creating Groups and Assigning Tunnels to Groups

Each Tunnel must be assigned to an individual group with newly discovered Tunnels being automatically assigned to a group with “Default” parameter set to On.

User can create multiple different groups and group tunnels in any way that is appropriate.

User can change Tunnel-to-Group assignment by using context menu or by using “Edit VPN Tunnel” button.

 

  1. Enabling Tunnel Monitoring

Once all Tunnels are discovered and added to a correct group you can enable monitoring on group level by setting “Enable Monitoring” check-button to “ON”

 

After “Enable Monitoring” flag is set to ON, Nectus starts checking Tunnel’s status every 5 min and creating records in Alert log along with sending Alert emails in case if Tunnel is down.

 

Real Time status for all tunnels can be seen in left side panel “VPN Tunnel”

By using right-click on Tunnel’s name you can access rich context menu where you can move tunnels to a different group, delete Tunnel, change Tunnel’s name or

View Tunnel’s Phase 1 and Phase 2 Information.

 

 

“View Tunnel Info” provides low level Phase 1

 

And Phase 2 Information along with encryption domain parameters and traffic counters

 

 

Nectus Installation Procedure

,

Nectus Installation Procedure

Server Requirements:   Windows Server 2012 or newer.  8GB of RAM.

1. File Preparation

You start with downloading Nectus Distribution File from www.nectus5.com

Download the ZIP file called Nectus 1.2.51.zip and extract it to a temporary folder.

In the folder you will find two files:

 

Keep the htdocs.zip file compressed. Start installation by launching file Nectus Setup 1.2.51.exe

2. Nectus Installation

Accept the license agreement on the first page.

 

Choose an application installation folder.

 

Choose whether you want Nectus to discover Network devices or not.

 

If you selected “Yes” for the Network Device Discovery, Specify the version of the SNMP Protocol.

 

Then specify SNMP credentials.

 

Specify up to 10 IP Subnets where Nectus will be performing Network Discovery.

 

 

Setup an Administrator account.

 

Then click install, which will automatically complete installation.

 

When the installation Is complete, you will see the following page.

 

After you click Finish, the Nectus login page will come up, where you need to provide the credentials of the admin account you created during Installation.

 

when you log into Nectus you will see a Network Discovery Progress page.

 

Click “OK” to close it.

3. License Generation

Next, the license page will come up.

If you do not have a permanent license ready, Click “Generate Temporary License” button.

 

Complete the “Temporary License” Form and press the “Generate Temporary License” button.

Nectus server must have an Internet access to successfully generate the temporary license.

After temporary license is generated, Nectus is fully operational and ready to be used.

 

Configuring Network Device Configuration Backup in Nectus 1.2.51

,

Network Device Configuration Backup

Nectus version 1.2.51 introduced several enhancements for Network Device Configuration backup procedure.

User can now use different backup credentials and fully customizable backup scripts for different Device Views. This allows user to create different backup scripts for different vendors or different product lines with different CLI.

User can control what configuration information is included in configuration backup and include supplementary information such as hardware inventory info, current ports status and list of connected devices to a scheduled configuration backup process.

Creating Device View for Configuration Backups

Very first step in setting up your configuration backup is to create Device Views that will contain devices that require common Credentials and Configuration Scripts.

For example, you can create Device View that will contain all Cisco ASA Firewalls and Separate Device View that will contain all Cisco IOS Devices.

The reason those devices require separate Device Views is that Configuration Backup script differ for ASA and IOS devices.

Also use different Device View if devices require different login credentials.

To Create a Device Views, go to Inventory → Views → SNMP Device Views

 

Creating Login Credential Sets

Next step is to define your login credentials that will be used by Configuration backup engine to login to devices and executing Backup Scripts.

To Create a Backup login Credentials, go to:

Settings → Device Configuration Backups → Backup Credentials

Creating Backup Scripts

Next step is to create Backup Scripts that will be executed by backup engine once it is logged in to device.

Here is the example of sample Backup Script for Cisco ASA Devices:

config terminal

pager 0

show running-config

You can further enhance backup script by including for example hardware inventory information command: “show inventory” etc.

It is important to create a script that will generate all the information required for backup without pagination.

To Create Backup Scripts, go to:

Settings → Device Configuration Backups → Backup Scripts

In some cases, output generated by backup script may contain highly sensitive information that may not be desired to be stored anywhere.

For cases like this Nectus offers “exclusion rules” option in Configuration Script definition where you can define which config lines must be excluded from the text before it is stored in database.

You can use RegEx syntax to define those exclusion rules.

Creating Backup Jobs

Next step is to create a Backup Job definition where you can combine Device View with specific Backup Credential Set and Backup Script.

To Create Backup Jobs, go to:

Settings → Device Configuration Backups → Backup Jobs

Enable Config Backup, Set Time and Miscellaneous Settings

And final step is to define time for scheduled backup and to turn it ON.

To set a time for Configuration Backup, go to:

Settings → Device Configuration Backups → Schedule

 

To enable configuration Backup go to:

Settings → Device Configuration Backups → General Settings

 

Additional Backup Parameters are available on “Backup Parameters” Tab where you can control for how long the backup files should be stored in DB

and whether you want you to backup up configuration if it has not changed since the last time it was backed up.

 

Note: Backup engine attempts SSH connection first and if SSH connection fails it will attempt a Telnet.

 

How to collect Interface-VLAN membership info from Cisco Switch via SNMP (CISCO-VLAN-MEMBERSHIP-MIB)

,

How to collect Interface-VLAN membership info from Cisco Switch via SNMP (CISCO-VLAN-MEMBERSHIP-MIB)

 

CISCO-VLAN-MEMBERSHIP-MIB contain several usefull OIDs for collecting Interface VLAN membership information from Cisco Swithes

1.3.6.1.4.1.9.9.68.1.2.2.1.1 (vmVlanType)

1.3.6.1.4.1.9.9.68.1.2.2.1.2 (vmVlan)

1.3.6.1.4.1.9.9.68.1.2.2.1.3 (vmPortStatus)

1.3.6.1.4.1.9.9.68.1.2.2.1.4 (vmVlans)

1.3.6.1.4.1.9.9.68.1.2.2.1.5 (vmVlans2k)

1.3.6.1.4.1.9.9.68.1.2.2.1.6 (vmVlans3k)

1.3.6.1.4.1.9.9.68.1.2.2.1.7 (vmVlans4k)

 

Lets see what our LAB switch reports on these for Interface with ifIndex = [4]

 

OID VLAN Memership Type: 1.3.6.1.4.1.9.9.68.1.2.2.1.1

1 = static, 2 = dynamic, 3 = multiVlan

Output Example: ‘1.3.6.1.4.1.9.9.68.1.2.2.1.1.4’ => “1” (VLAN statically assigned to this port)

 

OID VLAN ID of the Port: 1.3.6.1.4.1.9.9.68.1.2.2.1.1

Output Example: ‘1.3.6.1.4.1.9.9.68.1.2.2.1.2.4′ => “104” (Port is assigned to VLAN 104)

 

OID Port Status: 1.3.6.1.4.1.9.9.68.1.2.2.1.3

1 = Inactive, 2 = Active, 3 = Shutdown

Output Example: ‘1.3.6.1.4.1.9.9.68.1.2.2.1.3.4’ => “2” (Port is Active)

 

How to collect list of VLANs from Cisco Switch via SNMP (CISCO-VTP-MIB)

,

How to collect list of VLANs from Cisco Switch via SNMP (CISCO-VTP-MIB)

CISCO-VTP-MIB contain several useful OID for collecting VLAN information from Cisco Switches

 

1.    1.3.6.1.4.1.9.9.46.1.3.1.1.1 (vtpVlanIndex)

2.    1.3.6.1.4.1.9.9.46.1.3.1.1.2 (vtpVlanState)

3.    1.3.6.1.4.1.9.9.46.1.3.1.1.3 (vtpVlanType)

4.    1.3.6.1.4.1.9.9.46.1.3.1.1.4 (vtpVlanName)

5.    1.3.6.1.4.1.9.9.46.1.3.1.1.5 (vtpVlanMtu)

6.    1.3.6.1.4.1.9.9.46.1.3.1.1.6 (vtpVlanDot10Said)

7.    1.3.6.1.4.1.9.9.46.1.3.1.1.7 (vtpVlanRingNumber)

8.    1.3.6.1.4.1.9.9.46.1.3.1.1.8 (vtpVlanBridgeNumber)

9.    1.3.6.1.4.1.9.9.46.1.3.1.1.9 (vtpVlanStpType)

10.    1.3.6.1.4.1.9.9.46.1.3.1.1.10 (vtpVlanParentVlan)

11.    1.3.6.1.4.1.9.9.46.1.3.1.1.11 (vtpVlanTranslationalVlan1)

12.    1.3.6.1.4.1.9.9.46.1.3.1.1.12 (vtpVlanTranslationalVlan2)

13.    1.3.6.1.4.1.9.9.46.1.3.1.1.13 (vtpVlanBridgeType)

14.    1.3.6.1.4.1.9.9.46.1.3.1.1.14 (vtpVlanAreHopCount)

15.    1.3.6.1.4.1.9.9.46.1.3.1.1.15 (vtpVlanSteHopCount)

16.    1.3.6.1.4.1.9.9.46.1.3.1.1.16 (vtpVlanIsCRFBackup)

17.    1.3.6.1.4.1.9.9.46.1.3.1.1.17 (vtpVlanTypeExt)

18.    1.3.6.1.4.1.9.9.46.1.3.1.1.18 (vtpVlanIfIndex)

 

Note that output from out Lab Switch did not return any values for first OID: 1.3.6.1.4.1.9.9.46.1.3.1.1.1

 

VLAN State: 1.3.6.1.4.1.9.9.46.1.3.1.1.2

1 = Operational, 2 = Suspended, 3 = mtuTooBigForDevice, 4 = mtuTooBigForTrunk

‘1.3.6.1.4.1.9.9.46.1.3.1.1.2.1.1’ => “1”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.2.1.10’ => “1”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.2.1.100’ => “1”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.2.1.101’ => “1”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.2.1.102’ => “1”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.2.1.109’ => “1”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.2.1.1000’ => “1”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.2.1.1001’ => “1”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.2.1.1002’ => “1”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.2.1.1003’ => “1”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.2.1.1004’ => “1”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.2.1.1005’ => “1”

 

VLAN Type: 1.3.6.1.4.1.9.9.46.1.3.1.1.3

1 = Ethernet, 2 = FDDI, 3= TokenRing, 4 = FDDI, 5 = rtNet, 6 = Depreciated

‘1.3.6.1.4.1.9.9.46.1.3.1.1.3.1.1’ => “1”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.3.1.10’ => “1”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.3.1.100’ => “1”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.3.1.101’ => “1”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.3.1.102’ => “1”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.3.1.109’ => “1”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.3.1.1000’ => “1”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.3.1.1001’ => “1”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.3.1.1002’ => “2”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.3.1.1003’ => “3”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.3.1.1004’ => “4”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.3.1.1005’ => “5”

 

VLAN Name: 1.3.6.1.4.1.9.9.46.1.3.1.1.4

‘1.3.6.1.4.1.9.9.46.1.3.1.1.4.1.1’ => “default”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.4.1.10’ => “VLAN0010”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.4.1.100’ => “VLAN0100”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.4.1.101’ => “VLAN0101”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.4.1.102’ => “vlan102”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.4.1.109’ => “VLAN0109”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.4.1.1000’ => “VLAN1000”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.4.1.1001’ => “VLAN1001”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.4.1.1002’ => “fddi-default”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.4.1.1003’ => “token-ring-default”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.4.1.1004’ => “fddinet-default”

‘1.3.6.1.4.1.9.9.46.1.3.1.1.4.1.1005’ => “trnet-default”

 

How to collect list of MAC addresses from Cisco Switch via SNMP (dot1dTpFdbEntry)

,

How to collect list of MAC addresses from Cisco Switch via SNMP (dot1dTpFdbEntry)

One of the ways to get list of MAC addresses from the forwarding table of Cisco switch is via SNMP MIB: dot1dTpFdbEntry

This MIB branch contain three OIDs:

1.3.6.1.2.1.17.4.3.1.1 (dot1dTpFdbAddress)

1.3.6.1.2.1.17.4.3.1.2 (dot1dTpFdbPort)

1.3.6.1.2.1.17.4.3.1.3 (dot1dTpFdbStatus)

1.3.6.1.2.1.17.4.3.1.1 (dot1dTpFdbAddress) contain list of MAC addresses in Binary format

1.3.6.1.2.1.17.4.3.1.2 (dot1dTpFdbPort) contain IfIndex value of the interface associated with each MAC Address

1.3.6.1.2.1.17.4.3.1.3 (dot1dTpFdbStatus) contain Status code which gives information how each MAC was learned by the switch.

 

To get list of MAC address perform SNMP Get-Bulk request for “.1.3.6.1.2.1.17.4.3.1.1”

Here is the Example of output from our LAB Switch:

‘1.3.6.1.2.1.17.4.3.1.1.0.21.198.146.146.151’ => “ƒ’—”

‘1.3.6.1.2.1.17.4.3.1.1.0.25.185.178.231.213’ => “¹²çÕ”

‘1.3.6.1.2.1.17.4.3.1.1.0.33.216.202.216.128’ => “!ØÊ؀”

‘1.3.6.1.2.1.17.4.3.1.1.0.34.144.251.146.97’ => “”û’a”

‘1.3.6.1.2.1.17.4.3.1.1.0.80.86.156.43.191’ => “PVœ+¿”

‘1.3.6.1.2.1.17.4.3.1.1.0.80.86.156.49.102’ => “PVœ1f”

‘1.3.6.1.2.1.17.4.3.1.1.0.80.86.156.69.113’ => “PVœEq”

 

Notice that actual MAC Addresses returned look like some garbage characters but those are actually MAC address in ASCII format that needs to be converted to HEX to get a conventional xx:xx:xx:xx:xx:xx style.

Lets take last line: ‘1.3.6.1.2.1.17.4.3.1.1.[0.80.86.156.69.113]’ => “PVœEq”

If we take ASCII text (PVœEq) and convert to HEX,  we will get  50:56:9C:45:71

If we take Decimal [0.80.86.156.69.113] and convert to HEX, we will get 0:50:56:9C:45:71

So we have a MAC address on both sides.

 

To get list of associated Ports for each MAC address perform SNMP Get-Bulk request for “.1.3.6.1.2.1.17.4.3.1.2”

Here is the Example of output from our LAB Switch:

‘1.3.6.1.2.1.17.4.3.1.2.0.21.198.146.146.151’ => “2”

‘1.3.6.1.2.1.17.4.3.1.2.0.25.185.178.231.213’ => “2”

‘1.3.6.1.2.1.17.4.3.1.2.0.33.216.202.216.128’ => “1”

‘1.3.6.1.2.1.17.4.3.1.2.0.34.144.251.146.97’ => “1”

‘1.3.6.1.2.1.17.4.3.1.2.0.80.86.156.43.191’ => “2”

‘1.3.6.1.2.1.17.4.3.1.2.0.80.86.156.49.102’ => “2”

‘1.3.6.1.2.1.17.4.3.1.2.0.80.86.156.69.113’ => “2”

Values returned represent IfIndex values for corresponding Interfaces associated with each MAC Address. You need to use [ID substring] to match ifIndex value to MAC Address.

And finally, to get a Status code to each MAC address perform SNMP Get-Bulk Request for 1.3.6.1.2.1.17.4.3.1.3

 

Example of output from our LAB Switch:

‘1.3.6.1.2.1.17.4.3.1.3.0.21.198.146.146.151’ => “3”

‘1.3.6.1.2.1.17.4.3.1.3.0.25.185.178.231.213’ => “3”

‘1.3.6.1.2.1.17.4.3.1.3.0.33.216.202.216.128’ => “3”

‘1.3.6.1.2.1.17.4.3.1.3.0.34.144.251.146.97’ => “3”

‘1.3.6.1.2.1.17.4.3.1.3.0.80.86.156.43.191’ => “3”

‘1.3.6.1.2.1.17.4.3.1.3.0.80.86.156.49.102’ => “3”

‘1.3.6.1.2.1.17.4.3.1.3.0.80.86.156.69.113’ => “3”

Possible Values codes are

1 = Other

None of the following. This would include the case where some other MIB object (not the corresponding instance of dot1dTpFdbPort, nor an entry in the dot1dStaticTable)

is being used to determine if and how frames addressed to the value of the corresponding instance of dot1dTpFdbAddress are being forwarded.

2 = Invalid

This entry is no longer valid (e.g., it was learned but has since aged out), but has not yet been flushed from the table.

3 = Learned

The value of the corresponding instance of dot1dTpFdbPort was learned and is being used.

4 = Self

The value of the corresponding instance of dot1dTpFdbAddress represents one of the bridge’s addresses.

The corresponding instance of dot1dTpFdbPort indicates which of the bridge’s ports have this address.

5 = Mgmt

The value of the corresponding instance of dot1dTpFdbAddress is also the value of an existing instance of dot1dStaticAddress.

 

Important Note: This process may need to be adjusted if  “per-VLAN” SNMP Contexts being used. In that case you must repeat this process separately for each VLAN by adding “@n” to SNMP community string where “n” is the VLAN ID.

How to Add/Discover single SNMP Device in Nectus

,

How to Add/Discover Single SNMP Device in Nectus

Starting from Version 1.2.49 process of adding single device to Nectus database was greatly simplified and improved.

To discover single SNMP device open in Main menu Tools → Manual Discovery Start

In Manual Discovery window Select Partial Discovery and specify single IP address with /32 Mask for Subnet.

Press Start Button to start a Discovery process.

After Discovery starts you can monitor its progress in Discovery log located in

Top Menu Logs → Discovery Log

Each Discovery Job will have individual line in Discovery log

Manually Initiated Discoveries will have string “Manual” in Type Column as opposed to “Schedule” to scheduled automatic discoveries.

Each Discovery log record contain information about how many overall and new devices were discovered at each Discovery job.

If your manual Discovery job shows “0” New SNMP Devices discovered then you need to verify IP address, SNMP configuration and overall availability of device that you want to discover.

 

AWS System Variables for Email and SMS Alerts

,

This is the list of Nectus System Variables that can be used in AWS Monitoring Email or SMS Alerts.

AWS:
“%metric_name%”
“%metric_namespace%”
“%metric_value%”
“%unit_name%”
“%instance_id%”
“%instance_name%”
“%instance_region%”
“%current_time%”
“%time%”

Manual Network Discovery Operation

,

Manual Network Discovery Operation

Starting from Version 1.2.49 Nectus implements new and enhanced user interface for manually starting and stopping of Network Discovery.

To manually start network discovery, go to Tools → Manual Discovery Start

Where you will be presented with two options: Full Discovery and Partial Discovery

Full Discovery will perform ICMP/SNMP Scan on all subnets configured in global Network Discovery settings.

Partial Discovery gives an option to limit discovery to very specific subnets or single IP address.

In addition to Manual Start/Stop Option, Version 1.2.49 shows Discovery log with new column Type that differentiates Manual or Scheduled Discovery execution types.

 

Monitoring Windows Server Storage Utilization with Nectus

,

Monitoring Windows Server Storage Utilization with Nectus

In this chapter, you’ll learn how to use WMI to monitor Windows Server Storage Utilization. Nectus lets you create Profiles that specify which Servers to monitor with WMI and to send Alerts related to them. It also provides graphs of Server Utilization over time.

The specific topics we will cover in this chapter are:

  1. What is WMI?
  2. Why Monitor Windows Server Storage Utilization?
  3. Creating a WMI Server Group
  4. Adding a Server to the WMI Server Group
  5. Creating and Configuring a WMI Monitoring Profile
  6. Assigning a Profile to the WMI Server Group
  7. Viewing a Storage Utilization Graph

1. What is WMI?

WMI (Windows Management Instrumentation) is a set of specifications and interfaces that provides information about the status of local and remote computers running Microsoft Windows. In this chapter we look at how Nectus uses WMI to monitor the Storage Utilization on Windows Servers and send Alerts based on that information.

Note: WMI is the Microsoft implementation of the Web-Based Enterprise Management (WBEM) standard and the Common Information Model (CIM) standard from the Distributed Management Task Force (DMTF).

2. Why Monitor Windows Server Storage Utilization?

Monitoring when Storage Utilization goes outside of the expected Thresholds alerts you to various problems. For example, exceeding the Maximum Threshold could indicate that a Server needs a larger disk, or that some other application is using space on the disk. Utilization below the Minimum Threshold could indicate that data is not being received by the Server, or a problem is keeping the data from being written to the disk.

3. Creating a WMI Server Group

To create a WMI Server Group open the WMI Servers Panel on the Nectus Home Screen. Right-click the WMI Servers list. In the menu that appears, click Add New Group.

This opens the “Add New WMI Server Group” dialog box.

Enter a Group Name, then select the Email Groups and SMS Groups that will receive Alerts.

4. Adding a Server to the WMI Server Group

To add a Windows Server to the WMI Server Group right-click the Group and select Add New WMI Server.

This opens the “Add WMI Server” dialog box.

Enter the IP address of the Server you want to add to the Group. Alternately, you can move a Server from its current Group to this Group by right-clicking the Server and using the Move WMI Server to option.

5. Creating and Configuring a WMI Monitoring Profile

To create a WMI Monitoring Profile go to the Nectus Home Screen and select Monitoring -> WMI Monitoring Settings.

This opens the “WMI Monitoring Settings” dialog box.

Click Add Profile -> Disk.

Enter the Monitoring Profile Name and check the Enabled box next to the Disk Used Space metric. Check the types of Alerts you want the Profile to send.

Check the Default Profile box if you want to make this the new default WMI Monitoring Profile.

5.1 Editing Disk Used Space Options

Select the Disk Used Space Options icon to open the “WMI Options – Disk Used Space, %” dialog box.

Set the Alert Thresholds you want to monitor, as well as the number of Consecutive Readings that a Threshold must be exceeded before triggering an alert. Nectus checks the thresholds every 5 minutes, so setting Consecutive Readings to 3 means a value would need to exceed the assigned Threshold for 15 minutes before triggering an alert.

5.2 Editing Disk Used Space Alert Templates

To edit the format of Alerts return to the Disk tab of the “Add WMI Monitoring Profile” dialog box. Click the Disk Used Space Alert Templates icon to open the “Edit Alert Handler” dialog box.

6. Assigning a Profile to the WMI Server Group

In the WMI Servers Panel on the Nectus Home screen, open the WMI Servers list. Right-click the WMI Server Group and select Properties.

This opens the “Edit WMI Server Group” dialog box.

Select the WMI Monitoring Profile to use from the Monitoring Profile drop-down list.

Check the Enable Monitoring box to begin monitoring the Server Group using this Monitoring Profile.

7. Viewing a Storage Utilization Graph

To view a graph of Storage Utilization over time, right-click the Server you want information on and select Disk Used Space Graph.

This opens a “Disk Used Space Graph” which displays the changes in Storage Utilization over time.

 

List of system variables that can be used in Alert emails for SNMP Devices and Interfaces

,

List of system variables that can be used in Alert emails for SNMP Devices and Interfaces  (Version 2.48,  January 2019).

More system variables will be added in next releases.

 

Device Hostname:                %dev_hostname%
Device IPv4 Address:          %dev_ipv4_address%
Device IPv6 Address:          %dev_ipv6_address%
Device CPU Utilization:      %dev_cpu_utilization%
Device RAM Utilization:     %dev_ram_utilization%

Interface Name:                     %interface_name%
Interface Description:          %interface_description%
Interface Rx Utilization:      %interface_rx_utilization%
Interface Tx Utilization:       %interface_tx_utilization%

Device Site:       %dev_site_name%
Alert Time:        %time%

Outage Duration:      %outage_duration%

How to Configure Nectus Syslog Collector to use Local Storage

,

How to Configure Nectus Syslog Collector to use Local Storage

  1. To configure Nectus Syslog collector storage settings go to Main Menu

Settings → General Settings → Syslog Settings

  1. Configure Storage parameters according to this example:

“Syslog Remote Server DB Root Password” should be taken from this file:

C:\Program Files\Nectus\Web\Apache24\htdocs\protected\config\database.ini

  1. After Configuration is finished press “Test DB Connection” to test connectivity to DB

  1. After DB connectivity is Tested, Press “Run Integration Scripts” button to create required SQL Tables.
  2. After Integration Scripts has been executed, Restart Syslog collector service in

“Settings → Services Status”

After Syslog Service is Restarted it should be ready to process and store Syslog Traffic.

 

How to Configure Nectus NetFlow Collector to use Local Storage

,

How to Configure Nectus NetFlow Collector to use Local Storage

To configure Nectus Netflow collector storage settings go to Main Menu

Settings → General Settings → NetFlow Integration

Configure Storage parameters according to this example:

“NetFlow Remote Server DB Root Password” should be taken from this file:

C:\Program Files\Nectus\Web\Apache24\htdocs\protected\config\database.ini

After Configuration is finished press “Test DB Connection” to test connectivity to DB

After DB connectivity is Tested, Press “Run Integration Scripts” button to create required SQL

Tables.

After Integration Scripts has been executed, Restart NetFlow collector service in

Top menu “Settings → Services Status”

After NetFlow Service is Restarted it should be ready to process NetFlow Traffic and store it in local DB.

 

Monitoring DHCP Scope Utilization on Windows DHCP Servers with Nectus

, ,

Monitoring Scope Utilization on Windows DHCP Servers with Nectus

In this chapter, you’ll learn how to use Nectus to enable and configure DHCP Scopes utilization monitoring on Windows DHCP Servers.

Nectus allows network engineers proactively monitor amount of free IP addresses in DHCP scopes and generate E-mail or Text alerts when number of free IP address falls below preset thresholds.

Nectus can also generate alert when number of free IP address exceeds predefined threshold as it may indicate underlying network operation problems when network devices not able reach DHCP server for leases.

Nectus uses basic WMI interface to collect scope and lease statistics from DHCP servers.

The specific topics we will cover in this chapter are:

  1. What is WMI?
  2. Why Monitor DHCP Scopes?
  3. Creating a DHCP Server Group
  4. Adding DHCP Server to Server Group
  5. Creating and Configuring Monitoring Profile
  6. Assigning Monitoring Profile to Server Group

1. What is WMI?

Nectus uses Windows Server WMI interface to collect basic information about DHCP scopes such as total number of IP addresses and current number of active leases.

WMI (Windows Management Instrumentation) is a set of specifications and interfaces that provides information about the status of local and remote computers running Microsoft Windows. In this chapter we look at how Nectus uses WMI to monitor DHCP Scope Utilization  and send alerts based on that information.

Note: WMI is the Microsoft implementation of the Web-Based Enterprise Management (WBEM) standard and the Common Information Model (CIM) standard from the Distributed Management Task Force (DMTF).

2. Why Monitor DHCP Scopes?

Availability of free IP addresses is a critical requirement for modern network. When DHCP scope runs out of addresses users are not able to join your network.

Typical network segments that heavily dependent on DHCP are LAN and Wi-Fi Users.

Several DDOS attack types are specifically targeting DHCP infrastructure and by exhausting DHCP pools with fake lease requests can bring down any network to its knees.

Sometimes regular business growth can cause corresponding grows in IP address utilization and if left undetected can eventual cause an outage and service degradation for DHCP dependent applications.

3. Creating a DHCP Server Group

First step is to create a new Server Group for our DHCP Servers.

Go to the Nectus Home Screen and select WMI Servers -> WMI Servers. In the menu that appears, click Add New Group.

This opens the “Add New WMI Server Group” dialog box.

Complete the fields that define the new Group and set Enable Monitoring.

4. Add a DHCP Server to Server Group

Now we need to define our DHCP Server and add those to Server Group.

To add a Windows DHCP Server to the Server Group right-click the Group and select Add New WMI Server.

This opens the “Add WMI Server” dialog box.

Enter the IP address of the Server you want to add to the Group.

Note: You can move a Server between different Groups by right-clicking the Server and using the Move WMI Server to option.

5. Creating and Configuring Monitoring Profile

Monitoring Profile is a list of Metrics that can be applied to Server Group to tell Nectus which specific metrics must be monitored for given Server Group.

To create new Monitoring Profile to go Monitoring -> WMI Monitoring Settings and press

“Add Profile” button

Monitoring Profile Configuration Interface will appear.

Assign Profile Name and enable “DHCP Scope Usage” check-button on “DHCP” Tab

Configure Max/Max Threshold Values for Alerts by pressing on “Options” button

Note: Monitoring Interval is 5 min therefore 3 for “Consecutive Readings” value will trigger Alert

only if Threshold condition are True for 15 minutes.

6. Assigning Monitoring Profile to Server Group

Next and the final step is to assign Monitoring Profile to the DHCP Server Group that we created.

Right Click on DHCP Server Group in left side panel and Select “Properties”

Select Monitoring Profile from the list of available Profiles and Click on “Enable Monitoring” check-button.

We are all set and ready to start proactive monitoring of your DHCP Infrastructure.

Download the best IPAM    https://www.nectus5.com/download/

 

 

Importing subnets to IPAM from IGP routing protocols

,

Importing subnets to IPAM from IGP routing protocols

Most existing IPAM tools require manual subnet configuration, which is by far the most time-consuming step in IPAM deployment. Nectus offers unique automated features that make the initial configuration fast and easy. One such feature is an automatic import of subnets from the IGP routing protocols like OSPF, EIGRP, or ISIS. Here is how it’s done.

Importing subnets to IPAM from IGP

In the Main Menu, go to Inventory → IMAP Subnets and Reservations.

This opens an “IPAM Subnets” window with “IPv4 subnets” tab. Click the Import Subnets from Routing Table button.

In the “Import Subnet from IGP” dialogue box that appears, specify the IP address of the backbone router from which you’ll be importing subnets, and a destination IPAM container where the imported subnets will be placed. Press the Import button to preload the subnets.

Nectus displays preloaded subnets in a table format, for your confirmation. Press Yes button to confirm import of subnets, and they will automagically appear in the designated IPAM container.

 

Importing subnets to IPAM from DHCP servers

,

Importing subnets to IPAM from DHCP servers

One of the most time-consuming steps in IPAM deployment is initial configuration. Whether you have 5 or 1000 network subnets, most IPAM software products require manual configuration of subnets. Nectus offers unique automated features that make this initial configuration step fast and easy. One such feature is an automatic import of the subnets from the DHCP servers, which is done in 2 quick steps.

Adding DHCP servers to IPAM

Begin the process by configuring the DHCP servers on “IPAM integration” page. In the Main Menu, select Settings → General Settings → IPAM Integration.

This opens an “IPAM Integration” page. To add DHCP servers to IPAM, select the DHCP Servers tab and press the Add button to open the “Add DHCP Server” dialogue box. Fill in the server name, IP address and Type, and press the Save button for each DHCP server you want to add to IPAM.

Importing Subnets from DHCP Servers to IPAM

Once the DHCP servers are configured, you are now ready to start importing subnets. In the Main Menu, go to Inventory → IMAP Subnets and Reservations.

This opens an “IPAM Subnets” window with “IPv4 subnets” tab. Click the Import Subnets from DHCP Server button to open the “Import Subnet from DHCP Server” dialogue box.

Select the DHCP servers from which you’ll be importing subnets, and a destination IPAM container where the imported subnets will be placed. Press the Import button to preload the subnets.

Nectus displays preloaded subnets in a table format, for your confirmation. Press Yes button to confirm import of subnets, and they will automagically appear in your designated IPAM container.

 

Management Interface Selection for Network Devices

,

Management Interface Selection for Network Devices

In this chapter, you’ll learn how Nectus selects Management Interfaces for Devices that are found during Discovery phase. Nectus will automatically select Management Interfaces using its own default logic. It also supports user-defined selection for cases where this is appropriate.

The specific topics we will cover in this chapter are:

  1. Default Logic for Management Interface Selection
  2. User-Defined Logic for Management Interface Selection
  3. Applying Selection Rules to Existing Devices

1. Default Logic for Management Interface Selection

During Discovery, Nectus finds all SNMP Devices on the network. Every Device has one or more Interfaces. Some of those Interfaces will have IP Addresses assigned to them, and could be used as the Management Interface for that Device.

Nectus has default logic for selecting the Management Interface for each Device. It checks every Interface on a Device looking for potential Management Interfaces. To be considered for selection as the Management Interface, an Interface must meet the following requirements:

  1. It must have a unique IP Address. Nectus will not select an Interface that does not have an IP Address, or that has an IP Address identical to some other Interface on the network.
  2. It must be Up. Netus will not select an Interface that is not Up.

From this list of possible Management Interfaces, Nectus selects one according to this priority list:

  1. An Interface name that begins with Mgmt
  2. An Interface name that begins with Loopback
  3. An Interface name that begins with Vlan
  4. Interface with lowest IP Address

If Nectus finds an Interface name that begins with Mgmt, it will use this as the Management Interface. If it does not find an Interface name that begins with Mgmt, it will look for one that begins with Loopback, and so on.

If Nectus does not find an Interface whose name starts with Mgmt, Loopback, or Vlan, it will select the lowest numbered IP Address on the Device.

This default logic allows Nectus to automatically select the correct Management Interface in most situations. To handle situations where the default logic is not appropriate, Nectus supports user-defined logic for Management Interface selection.

2. User-Defined Logic for Management Interface Selection

Defining your own Management Interface selection logic makes sense in two situations:

  • When the naming convention for your Interfaces doesn’t match the default rules
  • When specific Interfaces have special naming requirements

When a Device has applicable user-defined Management Interface selection logic, Nectus looks for that Interface before applying the default logic. As with the default logic, user-defined Management Interfaces:

  1. Must have a unique IP Address.
  2. Must be Up.

To create user-defined logic for a specific Device type right-click the Device name. In the menu that appears, select View Device Info.

This opens the “View Device Info” dialog box.

On the General Info tab, find the SNMP Platform ID and click the icon to the right of it to copy the ID.

Note: All Devices with the same model number have the same SNMP Platform ID.

Next Step is to go to Settings -> Products and Categories -> SNMP OID Libraries.

Select SNMP OID Libraries.

This opens the “SNMP OID Libraries” dialog box.

Select Management Interface Name in the Filter by OID Type list. Nectus displays all the current user-defined Management Interface Selection rules.

Click the Add button to open the “Add” dialog box.

Enter the SNMP Platform ID and the Management Interface Name Nectus should use for this type of Device.

3. Applying Selection Rules to Existing Devices

Defining new Management Interface selection rules will have automatic effect on all devices that will be discovered after rule is created but does not automatically apply those rules to existing Devices.

You need to tell Nectus to apply those changes to existing Devices.

To apply the user-defined selection rules to existing Devices, return to the “SNMP OID Libraries” dialog box and click the “Apply to Existing Devices” button.

 

Cisco SNMP v3 Configuration Example for IOS Devices

,

This is basic configuration example of the SNMPv3 on IOS device.

This enables SNMP v3 with following parameters:

Authentication Protocol: MD5

Authentication Username: vconsole

Authentication  Password: nectus

Privacy (Encryption) Protocol: AES-256

Privacy (Encryption) Password: nectus

Configuration Example

====================

snmp-server group NECTUS_V3_GROUP v3 auth read TESTv3
snmp-server view TESTv3 mib-2 included
snmp-server user vconsole NECTUS_V3_GROUP v3 auth md5 nectus priv aes 256 nectus

Locating Orphaned subnets in IPAM

,

Locating Orphaned IPAM Subnets

One of the key features of good IPAM is ability quickly find subnets that are part of the defined address space but have not been explicitly added to list of subnets available for allocation.

These subnets are normally called “orphaned” and can be presented as white spaces within address space.

Orphaned subnets are normally occurring when you import IPAM subnets from external source such as IGP routing table where address space is not contiguously divided among all the existing subnets.

Lets looks at this simplified example of the logic required for locating orphaned subnets.

For example, user defined full address space as 10.0.0.0/8 (10.0.0.0 – 10.255.255.255)

and imported one subnet from IGP: 10.20.20.0/24 (10.20.20.0 – 10.20.20.255)

We can present full address space as a contiguous line starting from 10.0.0.0 and ending 10.255.255.255

Full IPv4 Address Space:

 

10.0.0.0 ———————————————————————————-10.255.255.255

 

 

Now let’s overlay single imported subnet into address space line:

 

 

10.0.0.0 ————-***Used*** —————————————————10.255.255.255

 

We see that there is some unused space to the left and to the right of the used space.

We need to find all the subnets that cover unused space so they can be presented in IPAM list of available subnets. The subnets that we are looking for must be largest subnets possible,

to minimize fragmentation.

Let’s summarize: Our goal is to find the largest subnet(s) that can be fit into the left and right empty segments.

Let first look at “left” empty space:

First IP 10.0.0.0 00001010‬.00000000.00000000.00000000
Last IP 10.20.19.255 00001010.00010100.00010011.11111111

We can see that First and Last IP address of “left” empty segment have matching highest 11 bits.

Largest subnet that will fit into “left” empty segment will have First and Last IP with following parameters:

First IP address:

  1. Has 00001010‬.000 in first 11 bits
  2. Has all zeros in Host portion
  3. Is greater or equal to 10.0.0.0

Last IP address:

  1. Has 00001010‬.000 in first 11 bits
  2. Has all ones in Host portion
  3. Is less or equal to 10.20.19.255

After checking all possible options matching IP addresses are discovered.

First IP 10.0.0.0 00001010‬.00000000.00000000.00000000
Last IP 10.15.255.255 00001010.00001111.11111111.11111111

This combination of First/Last IP gives us largest Subnet that will fit into “left” free segment as 10.0.0.0/12

We can see that 10.0.0.0/12 does not fully cover “left” empty segment so this discovery process has to be repeated for remaining empty space. Discovery may require several iterations until we get 100% coverage.

Similar approach must be applied to “right” empty segment until we identify all orphaned subnets and achieve 100% coverage of required address Space.

If your IPAM can’t perform this type of Discovery, you know where to download the best IPAM on the market: https://www.nectus5.com/download/

 

Splitting and Merging Subnets in IPAM

,

Splitting and Merging Subnets in IPAM

In this chapter, you’ll learn how and why to Split and Merge Subnets.

The specific topics we will cover in this chapter are:

  1. Why Split and Merge Subnets?
  2. How to Split Subnets
  3. How to Merge Subnets
  4. How to Move Subnets

1. Why Split or Merge Subnets?

Splitting and Merging Subnets lets you use your IP address space more efficiently. A full Class C Subnet has 256 usable addresses. But if you only need 30, using the full Subnet would result in a waste of over 200 IP addresses. Splitting the subnet would allow you to get the number of addresses you need, without wasting the rest. In addition, making a smaller Subnet reduces network traffic, as messages on that Subset are broadcast to fewer addresses.

Merging Subnets works the opposite. You may need a Subnet with 80 IP addresses, but instead have several smaller Subnets available. By merging smaller Subnets into one large one, you can use those addresses that might otherwise be wasted.

Nectus also allows you to move Subnets to different IPAM Containers. This makes it easy to reallocate IP addresses from their current location to the physical Sites that need them.

2. How to Split Subnets

To Split a Subnet go to the Nectus Sites Panel and select IPAM > All IPv4 Containers.

Nectus displays all existing IPAM Containers and any Unassigned Subnets. To see how many IP addresses are available in any Subnet, right-click it. In the menu that appears, select View Subnet Info.

This opens the “Subnet View Info” dialog box.

The Total IPs field on the General Info tab shows how many IPs the Subnet contains.

Navigate to the Subnet you want to split and right-click it. In the menu that appears, select Split.

This opens the “Split Subnet” dialog box.

The New Subnet Size list shows you the ways you can split the selected Subnet.

The Place New Subnets to: list allows you to assign the new Subnets you create to any existing IPAM Container.

3. How to Merge and Subnets

To Merge two or more Subnets go to the Nectus Sites Panel and select IPAM > All IPv4 Containers.

Navigate to the Subnets you want to merge and select each one. The Subnets you want to Merge must be contiguous, as in the screenshot below. Right-click one of the Subnets and in the menu that appears, select Merge Subnets.

This opens the “Merge Subnets” dialog box. The dialog box shows you which Subnets will be merged, and gives you the option to place the merged Subnet in any IPAM Container.

4. How to Move Subnets

You can move a Subnet without Splitting or Merging it. To move a Subnet to a different IPAM Container right-click the Subnet.

In the menu that appears, select Move Subnet to… and navigate the list of Containers to select the new location.