This is an example on how to obtain list of IP addresses assigned to Interfaces inside specific SNMP Context on Nexus 7000

Step 1.

Obtain list of all SNMP Contexts by sending SNMP GET Bulk for cContextMappingVrfName (.1.3.6.1.4.1.9.9.468.1.1.1.2)

Response:

‘1.3.6.1.4.1.9.9.468.1.1.1.2.10.109.97.110.97.103.101.109.101.110.116’=>”management”

In this response Nexus 7018 Switch has only one SNMP context with a name “management”

 

Step 2.

Obtain list of all IP addressses that exist in context “management” by sending SNMP GET Bulk for ipAdEntIfIndex (.1.3.6.1.2.1.4.20.1.2)

Note that for this step step we have append context name to V2 community string

(e.g public@management) to specify that this request is specific for context “management”.

Response:

‘1.3.6.1.2.1.4.20.1.2.10.255.27.34’=>”83886080″

In this response we have IP address [10.255.27.34] and associated interface ifIndex “83886080”

 

Step 3.

Find interface name with ifIndex 83886080 by sending SNMP GET Bulk for (.1.3.6.1.2.1.2.2.1.2)

Response:

‘1.3.6.1.2.1.2.2.1.2.83886080’ => “mgmt0”

 

So in these 3 steps we have found that  Interface Mgmt0 has assigned an ip address 10.255.27.34

 

Following ports needs to be opened for inbound access to Nectus GUI via Firewall

HTTPS: TCP 443

WebSockets: TCP 8000, 8100

CST signs partner agreement with Cisco Learning Academy to provide

Network Visualization and Discovery tools to be used in training classes.

 

 

 

Very often our customers  has to live trough the M&A process where merging networks are configured with different SNMP parameters.

It can be just different  SNMP v2 community strings of different flavors of ciphers in SNMP v3.

To support multiple SNMP settings within the single management domain Nectus implements a concept of SNMP profiles.

User can define up to 10 different SNMP profiles and Nectus Discovery will try them all in predefined order.

For each live IP address Nectus discovery will try each of the profiles until match is found.

Once correct profile is found it gets associated with specific device or IP address  and all further SNMP communications

for this specific device will be done with its “good”  SNMP profile.

To configure  SNMP profiles “Settings -> Network Discovery Settings -> SNMP Profiles”

 

 

You can share graphs generated in Nectus with other  people by providing graphs’ direct URLs from the right upper cortner

 

To reassign device to a different site right click on the device name and select “Move Device to..” option in context menu

To start a web-based SSH session to any device right-click on device and select “Open SSH Session” in context menu

(session will originate from Nectus server IP)

To create a new command script open  “Tools->Command Scripts” in main menu and select “Add New Script” Button.

Here is an example of the Script for Cisco router to push AAA config change.

 

To push the command script to devices, Press “Play” button, Select target Device View and press “Run”

Starting from Nectus version 1.2.6 Ping plotter functionality was added to a Toolset located in  “Tools” main menu.

Specify up to 10  IP address and track latency and availability in real time. Export metrics to a CSV file with 1 second resolution.

 

All network devices that responds to SNMP queries are being placed in “All SNMP Devices” category,

furthermore Nectus tries to obtain list of all CDP neighbors from SNMP enabled devices and  tries to communicate

to all CDP neighbors via SNMP. If CDP neighbor does not answer to SNMP queries is is being placed in “ALL CDP Devices”

category. So devices in “ALL CDP devices” category support CDP but don’t support (or answer) to SNMP queries.

Some of the devices that are normally seen in “ALL CDP devices” category: IP Phones, LWAP Access Points.

All devices with misconfigured or disabled SNMP  will appear there as well.

 

 

 

When SNMP enabled  device is discovered for the first time it is placed in default group “Unassigned” in “All Sites” category.

User must manually move devices from “Unassigned” group to specific site where each device belongs to.

Initially each Site has to be manually defined. To create a Site right click on “All Sites” and select “Create New Site Level” in context menu

 

Define Site name, GPS coordinates  and Address

 

If  your devices share common hostname format with site specific prefix you can automate the placement of devices into each site

by defining a hostname prefix for this site.  This will ensure that all devices with the same prefix will be placed into  this Site.

 

Nectus comes with hundreds of standard device icons but sometimes user may want

to change default icon for specific device type to something different.

Supported icon format is  SVG with width=”168px” height=”114px.

To change device icon, right click on Device Category and select “Properties”

 

 

Select “Upload SVG icon from Local Disk

 

Starting from version 1.28 Nectus supports processing of inbound Netflow packets.

To enable Netflow functionality separate standalone Server or VM is required for Storage.

64 bit MySQL Server has to be installed on Netflow storage VM and DB Name, Root credentials and TCP port

for Netflow Storage DB  has to be configured on main Nectus Server under “Settings -> General Settings -> Netflow Integration”

 

Netflow Collector can support up to 30,000 flow per second.

 

 

In addition to monitoring SNMP enabled devices located inside of your network Nectus can be configured to monitor

ICMP reachibility of any external IP address by adding it to a list of “IP Monitors”

First you need to  define IP Monitor Group name where IP address will be added to:

Make sure that “Monitoring” flag is selected. Unchecking this flag stops monitoring if this Group.

and second add actual IP address to the IP Monitor Group and assign it a name.

Each IP monitor has a context menu with different reports such as Latency, Lost Pings, UP/DOWN Status etc..

 

 

For each router or switch found during discovery Nectus has to select one interface that will be used as a primary monitoring

interface for basic reachibility checks, destination for SNMP  queries etc..

Here is the selection order logic that implemented in Nectus Discovery Service:

  1. Select Interface that has assigned IP address associated with current DNS record for device Hostname
  2. Select Interface that starts with “Mgmt” (for example: Mgmt0)
  3. Select Interface that starts with “Loopback” (Lowest number if preferred)
  4. Select Interface that starts with “VLAN”  (Lowest number of preferred)
  5. Select Interface with lowest IP Address

 

To exclude specific subnet from Network  Discovery add it to “Excluded subnets” list  in “Settings -> Network Discovery Settings”

This will exclude this subnets from ICMP scan phase and subsequently prevent live devices in this subnets from being

queried  via SNMP.

 

By default when you create a GRE tunnel  (tunnel-ip1) on ASR9K routers it gets assigned default Bandwidth value of 8Kbps

which usually causes utilization monitoring confusion as Tunnel can carry as much traffic as its hardware parent interface

where tunnel is anchored to. You would see utilization values as high a 10,000% percent with default Bandwidth settings.

To fix this issue correct bandwidth value has to be assigned to Tunnel interface.

Ideally it has to match Bandwidth value from the parent hardware interface.

Example:

interface tunnel-ip1
description BBL-0000: INTERNET-VPN-TO-JP
bandwidth 10000000
ipv4 address xx.xx.xx.xx/30
load-interval 30
tunnel mode gre ipv4
tunnel source yy.yy.yy.yy
keepalive 10
tunnel destination zz.zz.zz.zz
tunnel dfbit disable

During network discovery phase Nectus collects S/N for each device that responds to basic SNMP queries.

One of the problem with Cisco  Devices is that different platforms uses different OID to store S/N.

Following OIDs are being used for Cisco:

.1.3.6.1.2.1.47.1.1.1.1.11.1

.1.3.6.1.2.1.47.1.1.1.1.11.2

.1.3.6.1.2.1.47.1.1.1.1.11.10

.1.3.6.1.2.1.47.1.1.1.1.11.22

.1.3.6.1.2.1.47.1.1.1.1.11.1001

.1.3.6.1.2.1.47.1.1.1.1.11.24555730

.1.3.6.1.4.1.14179.1.1.1.4.0

.1.3.6.1.4.1.2467.1.34.4.0

.1.3.6.1.4.1.437.1.1.3.1.22.0

.1.3.6.1.4.1.9.20.1.1.1.1.3.0.1.3.6.1.4.1.7505.1.1.1.0

.1.3.6.1.4.1.9.6.1.101.53.14.1.5.1

.1.3.6.1.4.1.9.9.92.1.1.1.2.1

.1.3.6.1.4.1.9.3.6.3.0

.1.3.6.1.4.1.3076.2.1.2.22.1.63.0

.1.3.6.1.4.1.9.5.1.2.19.0

.1.3.6.1.4.1.9.9.719.1.9.35.1.47.1

Just run into a IOS-XR bug with running SNMP v3 with AES-128 cipher (as well as AES-192 and AES-256) on ASR 9000 Routers running 5.3.4 Code.

Apparently Cisco BUG ID CSCvd35831. Fixed in 6.2.xx code.

Upgrading ASR9K is fun that can take 4-5 hours per box but having SNMP communications secure is more important. Consider upgrading.

https://quickview.cloudapps.cisco.com/quickview/bug/CSCvd35831