iSPI Network Engineering toolset
When an issue on the network
occurs, the operator needs to troubleshoot the issue and often a
sequence of additional action is required, such as checking the current
status of interface, getting node configuration, evaluating outage
impact, or collecting information about end nodes connected to switch.
Another headache for
system administrators and operators is constant and meaningless SNMP
traps, which floods the message browser and cause event storms. This can
be caused by some improperly configured settings on group of nodes, or
constant and frequent event generation on one node.
All these issues are solved
by iSPI NET. It is a set of tools, which helps in troubleshooting
network issues. In general, there are three major features in this iSPI:
iSPI diagnostics
iSPI diagnostics helps to collect additional configuration data from network devices, such as:
Current configuration for Cisco router, Cisco switch, or Nortel switch
Diagnostic checks on a specified interface on Cisco router
Gather routing information
To configure this automatic diagnostics gathering, you need to complete following steps in SNMP Trap Configuration, Remote NNMi 6.x/7.x Event Configuration, or Management Event Configuration forms:
Specify node group in Configuration Per Node Group form
In the Diagnostic Selection, select which diagnostics you want to use
Diagnostic must be valid for a node which runs diagnostics. That is, Cisco configuration can run only on Cisco devices.
Incident's lifecycle state must match state which was configured. That is, if lifecycle state is closed, then diagnostics will run only when incident's state would be closed.
Troubleshooting tools
This tool examines
switches, detects and maps switch ports with end nodes connected to
them. End nodes don't need to be discovered by NNMi, as this data is
queried from the switch's ARP table. Using this data collection method,
the troubleshooting tool provides the following information:
Which switch port the node is connected to. It can be searched by IP address, node name, or MAC address.
All nodes attached to switch.
This functionality is very
useful for troubleshooting LAN issues. Many NNMi users were complaining
about the lack of this feature in previous NNMi versions (7.x and
earlier).
Trap analytics
By default, NNMi measures
the rate of incoming traps (incoming trap rate for each device and rate
of each incoming trap for each trap OID). If the rate of incoming traps
exceeds the defined threshold, NNMi blocks such traps until the rate
decreases below the minimum threshold limit.
Thresholds can be configured by the administrator using nnmtrapsconfig.ovpl script.
SNMP trap analytics allows you to get reports based on this trap information, by the following criteria:
Amount of traps within a specific time period
Trap amount for specified node
Trap amount to a specific trap identifier—OID
All data is logged to trapanalytics.0.0.log file. This file provides following data for specific time intervals:
This data is useful in
making analysis of SNMP traps, which allows us to optimize messages from
your managed network. Many administrators are complaining that they
receive too many messages. In many cases, administrators say they have
no idea where to start. So, start from the largest troublemakers—TOP 10
OIDs and TOP 10 sources. If you fix at least TOP 5 OIDs, you will reduce
the amount of alarms by 40-80%. So, even if the situation looks
hopeless, there is a small and easy way to make the step between a messy
and shining browser.
iSPI IP Telephony
HP NNMi Smart Plug-in for
IP Telephony extends the functionality of NNMi, providing more detailed
information about the VoIP telephony infrastructure. iSPI for VoIP
discovers, monitors, and presents additional views of VoIP specific
parameters, such as:
IP address, hostname, version, model, type, and status of device
Phone model, registration state, extension number, and supported protocol controller
VoIP network health
First of all,
your VoIP devices will be discovered automatically and presented on a
map as VoIP-specific devices, so that you can easily recognize VoIP
phone, PBX, or voice gateway on a map.
The NNMi SPI for IPT provides
comprehensive monitoring for an IP telephony service. It includes
features, which are VoIP specific: voice gateway, calls, and path
control.
Using iSPI for IPT
monitoring is more detailed than IP generic monitoring, and gives an
advantage for VoIP-specific issues against plain NNMi monitoring of IP
network. iSPI for IPT helps detect outages in their early stage.
The quality of calls has been
reduced, so more calls are dropped or being provided with long voice
delays. Using plain NNMi, you wouldn't recognize such behavior and you
would have green
map with no incidents regarding this issue, while your IPT users are
struggling and complaining about poor quality. iSPI for IPT would notify
you about such (and even more) service decreases, so the only thing you
should take care of is to fix a problem.
The following list provides a detailed feature list, which is supported by iSPI IPT:
Infrastructure management:
Call Manager 5.x, 6.x inventory, detail views, and status/incident.
Cisco GK inventory, detail views, and status/incident.
Cisco ICT inventory, detail views, and status/incident.
Nortel CS 1000, Nortel SS, and Nortel VGMC/MGC/MC inventory, detail views, and SNMP trap-based alarm status.
IP phone management:
Inventory and detail view of Cisco IP phones (SCCP/SIP), their registration status and their relationship to Call Managers.
Inventory and detail view of Nortel IP phones, their relationships to Nortel CS.
Detailed Cisco Voice Gateway management:
Cisco DS0 channel inventory, detail view, alarm status, usage status.
Cisco
DS1 (T1/E1 CAS/PRI/BRI, E&M, FXS, and FXO) Circuit Switched
interface inventory and detail view, alarm status/incident, and usage
incident/status.
Cisco VGW inventory and detail view, alarm status/incident, usage status/incident, H323 and MGCP support.
Voice quality monitoring and diagnostics:
CDR/CMR-based Jitter, latency, delay, MOS monitoring for calls in Cisco IPT networks and incidents.
Nortel QoS zone inventory, detail view with 32 QoS metric values for Nortel QoS zones and incidents.
Nortel QoS SNMP trap-based monitoring of quality of calls in Nortel IPT network and incidents.
Voice path draws L2/L3 path between two Cisco IP Phones for media.
Control path draws L2/L3 path between a Cisco IP Phone and its Call Manager.
No localization support on iSPI for IP Telephony.
iSPI for MPLS
iSPI for MPLS helps to
monitor MPLS-specific parameters. It uses NNMi's node inventory and
provides MPLS-specific, real-time data for MPLS-enabled devices:
MPLS Virtual Private Networks (VPN) on provider edge devices.
MPLS Pseudo Wire Virtual Containers (VC).
Traffic Engineering (TE) tunnels.
Monitors status and displays VPNs, VRFs, TE tunnels, and Pseudo Wire VCs attributes.
Generates incidents for the MPLS-specific faults or changes in the topology.
The following figure
represents the difference between managing MPLS-enabled network using
plain NNMi (left-hand side picture) and using iSPI MPLS (right-hand side
picture):
iSPI MPLS automatically
discovers MPLS devices and presents MPLS-specific data like L3-VPN/VRF,
L2VPN (Pseudo Wire), and MPLS traffic engineering. MPLS specific views
and implemented correlation are provided on MPLS specific incidents.
MPLS is supported only on Cisco IOS, IOS XR.
iSPI MPLS does not support localization.
The detailed feature list of iSPI for MPLS is as follows:
iSPI multicast
IP multicast is a
technique for one-to-many communications over an IP infrastructure in a
network. It scales to a larger receiver population by not requiring
prior knowledge of who or how many receivers there are. Multicast uses
network infrastructure efficiently by requiring the source to send a
packet only once, even if it needs to be delivered to a large number of
receivers. Multicast mostly is used for services such as video or audio
broadcasting, when many users may be watching/listening for the same
content. The nodes in the network take care of replicating the packet to
reach multiple receivers only when necessary. The most common low-level
protocol to use multicast addressing is User Datagram Protocol (UDP). By its nature, UDP is not reliable—messages may be lost or delivered out of order. Reliable multicast protocols such as Pragmatic General Multicast (PGM) have been developed to add loss detection and retransmission on top of IP multicast (source—Wikipedia).
The following figures represent Multicast's graphical presentation:
iSPI Multicast
allows monitoring multicast networks. It automatically detects multicast
configuration, shows multicast-specific views, and monitors
multicast-specific parameters. iSPI Multicast allows the user to
diagnose issues in early stage, which leads to the reducing of MTBF.
iSPI Multicast provides information like Multicast Node/Interface
inventory, including a designated router, discovers Multicast neighbors
and provides Multicast neighbor's status.
iSPI Multicast is supported only on Windows.
iSPI Multicast supports only Cisco IOS.
The following screenshot provides iSPI for Multicast window in NNMi:
