NetSocket Service Visibility Solution Suite

Service Visibility Point

Configuration Guide

Release 1.9

THE PRODUCT INFORMATION PRESENTED WITHIN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT NOTICE. ALL PRODUCT INFORMATION IS BELIEVED TO BE ACCURATE, BUT IS PROVIDED WITHOUT WARRANTY OF ANY KIND, EXPRESSED OR IMPLIED. NETSOCKET, INC. ACCEPTS NO RESPONSIBILITY FOR USERS SPECIFIC APPLIC ATION OF THE PRODUCT(S) FEATURED WITHIN THIS DOCUMENT. NEITHER NETSOCKET, INC. NOR ITS SUPPLIERS SHALL BE LIABLE FOR DAMAGES OF ANY KIND, INCLUDING, BUT NOT LIMITED TO, LOSS OF DATA OR REVENUE, ARISING FROM THE USE OF THE FEATURED PRODUCT(S) AND ASSOCIATED INFORMATION PRESENTED WITHIN THIS DOCUMENT.

NETSOCKET INC., CONFIDENTIAL THE INFORMATION CONTAINED IN THIS DOCUMENT IS THE PROPERTY OF NETSOCKET. EXCEPT AS SPECIFICALLY AUTHORIZED IN WRITING BY NETSOCKET, THE HOLDER OF THIS DOCUMENT SHALL KEEP THE INFORMATION CONTAINED HEREIN CONFIDENTIAL AND SHALL PROTECT SAME IN WHOLE OR IN PART FROM DISCLOSURE AND DISSEMINATION TO THIRD PARTIES AND USE SAME FOR EVALUATION, OPERATION AND MAINTENANCE PURPOSES ONLY. THE CONTENT OF THIS DOCUMENT IS PROVIDED FOR INFORMATION PURPOSES ONLY AND IS SUBJECT TO MODIFICATION. IT DOES NOT CONSTITUTE ANY REPRESENTATION OR WARRANTY FROM NETSOCKET AS TO THE CONTENT OR ACCURACY OF THE INFORMATION CONTAINED HEREIN, INCLUDING BUT NOT LIMITED TO THE SUITABILIT Y AND PERFORMANCES OF THE PRODUCT OR ITS INTENDED APPLICATION.

NetSocket 2012

Table of Contents
1 Introduction ................................................................................................................................ 1-1 1.1 1.2 1.3 1.4 2 About the Document ........................................................................................................ 1-1 Audience .......................................................................................................................... 1-1 How to Get Help .............................................................................................................. 1-1 Product Documentation ................................................................................................... 1-1 Session2Topology Correlation ..................................................................................... 2-1 SVM ................................................................................................................................. 2-2 SVP .................................................................................................................................. 2-2 SVA .................................................................................................................................. 2-2 2.4.1 2.4.2 2.5 3 SVA Standard IP MOS Monitoring ...................................................................... 2-3 SVA IP MOS Plus Analogue ............................................................................... 2-3

System Overview ...................................................................................................................... 2-1 2.1 2.2 2.3 2.4

SVM Dashboard .............................................................................................................. 2-3

Initial System Access ................................................................................................................ 3-1 3.1 3.2 3.3 3.4 1U Server......................................................................................................................... 3-1 2U Server......................................................................................................................... 3-2 CLI Access using the Default IP Address ........................................................................ 3-2 CLI Access using the Serial Ports ................................................................................... 3-3 3.4.1 3.4.2 3.5 System Serial Ports ............................................................................................. 3-3 Accessing the CLI from a Serial Port .................................................................. 3-4

CLI Access using a Monitor and Keyboard ..................................................................... 3-4

General System Configuration .................................................................................................. 4-1 4.1 System Configuration Example ....................................................................................... 4-1 4.1.1 4.1.2 4.1.3 4.1.4 General Configuration ......................................................................................... 4-2 TACACS Configuration ....................................................................................... 4-4 Maintenance Window Configuration ................................................................... 4-6 Host Login Lockout Resolution ........................................................................... 4-6

SVP Configuration ..................................................................................................................... 5-1 5.1 5.2 5.3 SVP Configuration Example Network .............................................................................. 5-1 SVP License .................................................................................................................... 5-2 SVA Monitoring ................................................................................................................ 5-2

SVP Session Monitoring Configuration ..................................................................................... 6-1 6.1 6.2 Session Signaling Monitoring Interface Configuration .................................................... 6-1 Session Signaling Monitoring Options ............................................................................. 6-2

SVP Network Monitoring Configuration ..................................................................................... 7-1 7.1 Complete Example Configurations .................................................................................. 7-2

NetSocket, Inc. - Proprietary and Confidential

Table of Contents

7.1.1 7.1.2 7.2 7.3

SVP Configuration Example ................................................................................ 7-2 Cisco Router Configuration Example .................................................................. 7-4

Topology Map Configuration ........................................................................................... 7-5 Router Configuration ....................................................................................................... 7-5 7.3.1 7.3.2 7.3.3 7.3.4 7.3.5 7.3.6 7.3.7 7.3.8 7.3.9 Adding a Router .................................................................................................. 7-6 Configuring SNMP Read-Only Access to the Routers ........................................ 7-6 Configuring CLI Read-Only Access to the Routers ............................................. 7-7 Configuring Route Table Polling ......................................................................... 7-8 Configuring Load Distribution Polling .................................................................. 7-9 Configuring QoS Statistics Polling ...................................................................... 7-9 Configuring NetFlow / Jflow Statistical Collection ............................................. 7-10 Configuring First Hop Router Redundancy Polling ........................................... 7-11 Configuring Routers to Send SNMP Traps to the SVP ..................................... 7-12 OSPF Configuration .......................................................................................... 7-13 BGP Configuration ............................................................................................ 7-14

7.4

SVP Router Peering Configuration ................................................................................ 7-13 7.4.1 7.4.2

SVP Threshold Configuration .................................................................................................... 8-1 8.1 8.2 8.3 Link Based Thresholds .................................................................................................... 8-1 Session Path Based Thresholds ..................................................................................... 8-2 Session Based Thresholds .............................................................................................. 8-3

SVP Network Security Configuration ........................................................................................ 9-1 9.1 9.2 SVP Network Services .................................................................................................... 9-1 SVP Interface Security .................................................................................................... 9-1 9.2.1 SVP EM Interface Security .................................................................................. 9-1

10

SVP Show and Debug Commands ......................................................................................... 10-1

NetSocket, Inc. - Proprietary and Confidential

ii

Introduction
The NetSocket solution consists of the Service Visibility Manager (SVM), the Service Visibility Point (SVP), and the Service Visibility Analyzer (SVA). This document provides basic description of the SVM, SVP, and SVA, as well as a web-based Graphical User Interface (GUI) called the SVM Dashboard.

1.1

About the Document

This Configuration Guide describes the steps used to configure the NetSocket visibility solution. A brief overview of the solution at the beginning of the document is followed by configuration examples.

1.2

Audience
The Configuration Guide is intended for the individuals tasked with the turn-up and configuration of the SVM, SVP, and SVA in the customers network.

1.3

How to Get Help

To receive technical support, contact NetSocket in one of the following ways: NetSocket technical support e-mail address: support@netsocket.com Visit the NetSocket Support Portal at http://www.support.netsocket.com.

1.4

Product Documentation
Following is the list of all documents included into the product documentation suite: Software Release Notes Installation Guide contains installation procedures. User Guide contains description and explanation of the SVM, SVP, and SVA functionality. The User Guide is intended for SVM Dashboard users. SVM Configuration Guide contains details and examples of the commands used to configure an SVM. SVP Configuration Guide contains details and examples of the commands used to configure an SVP. SVA Configuration Guide contains details and examples of the commands used to configure an SVA. Command Reference contains CLI command definitions. SVM SNMP Reference contains information about NetSockets proprietary MIBs and SNMP Traps.

NetSocket, Inc. - Proprietary and Confidential

1-1

System Overview
The NetSocket Visibility Solution provides real-time IP service assurance in Fixed Mobile Convergence (FMC), IP MPLS, and Enterprise environments by performing Session2Topology correlation for real-time IP services such as VoIP and Video. The solution consists of three system types: The Service Visibility Manager (SVM) is an element management system for the SVPs and SVAs. The SVM provides a web based GUI, called the Dashboard, used to monitor the NetSocket Visibility Solution. The Service Visibility Point (SVP) is a server appliance that monitors the layer-3 IP network and the layer-4 session signaling. The Service Visibility Analyzer (SVA) is a server appliance that monitors and analyzes RTP media streams associated with the sessions monitored by the SVP. The NetSocket Visibility Solution works in a hierarchical model where one SVM monitors one or more SVPs and an SVP can monitor zero or more SVAs. After the initial configuration, the user accesses and monitors the entire solution via the SVM Dashboard. This chapter provides a functional overview of the SVM, the SVP and the SVA. The following topics are covered within this chapter: Session2Topology Correlation SVM SVP SVA SVM Dashboard

2.1

Session2Topology Correlation
As the name suggests, this key technology automatically correlates the real-time state and changes in the IP network to the individual sessions being carried through that network. In real-time, the NetSocket solution knows the exact hop-by-hop path of any session, and can identify what network event has impacted, or is impacting, that session. Further, this same knowledge is used to proactively alert the service manager to changes in network configuration that can impact the traffic on the network. Unique aspects of the Session2Topology correlation engine include: Works in real time to create a service assurance mashup, providing a dynamic "map" of the network onto which media and application/service information is correlated. Monitors the network without imposing any burden on the deployed network nodes, such as routers; it passively participates in the routed network using standard IP routing protocols.

The results of the Session2Topology correlation are presented in the Quality of Session Record (QSR).

NetSocket, Inc. - Proprietary and Confidential

2-1

System Overview

2.2

SVM
The Service Visibility Manager is a management node for the SVPs and SVAs deployed in a network. For each application, the SVM provides metrics applicable to that application. In addition, the SVM provides Fault, Configuration, Accounting, Performance, and Security (FCAPS) management for the SVPs deployed. The SVM receives operational information from all the SVPs within the network, which is then displayed on the SVM Dashboard. An industry compatible Command Line Interface (CLI) is also supported by the SVM. The CLI is used for configuration and maintenance. A user can access the CLI remotely through the SVMs Ethernet ports, or locally through the console serial ports. Remote CLI access is through SSH or Telnet. CLI access authentication and authorization can be enabled via RADIUS or TACACS+. Further, the solution allows a user to configure access lists to filter incoming or outgoing traffic on any interface. SNMP traps can be used to provide the operators NMS/OSS with SVM fault/alarm information. The SVM supports SNMP v1 and v2c for this purpose.

2.3

SVP
The Service Visibility Point provides a way to monitor user traffic (i.e., sessions) in a routed IP network, giving carriers the power to understand how these sessions traverse their IP networks. It determines the paths taken by sessions through an IP network, stores information pertaining to the sessions, and provides real-time and historical operational statistics for the network. With this understanding, service providers can quickly identify and rectify issues, increase operational efficiency, and improve customer satisfaction. The SVP learns network topology and status of available network resources by using standard IP routing protocols, such as OSPF and BGP, and by collecting information from the monitored routers using SNMP and CLI. The SVP passively monitors signaling information exchanged with the session control node (e.g., Femtocell Gateway in a Femtocell deployment, a Call Controller in a VoIP deployment, etc.) to obtain real-time session information. This information is correlated to the IP network topology monitored in real-time by the SVP. This correlation is called Session2Topology correlation, and is key to the network visibility provided by the NetSocket solution. As sessions are established and released, the SVP maintains operational metrics about each session. If these metrics deviate outside the normal operational range (based on user defined thresholds), the SVP alerts the Operations team of potential problems and provides a list of affected sessions. This allows proactive management of the network and can significantly reduce the Mean Time to Isolate (MTTI) in problem resolution.

2.4

SVA
The Service Visibility Analyzer analyzes voice and video RTP streams associated with the sessions monitored by an SVP. Each SVA provides four 10/100/1000 Ethernet monitoring interfaces or two 10-Gigabit Ethernet monitoring interfaces. The SVA can be deployed with two different monitoring configurations: standard IP MOS monitoring and IP monitoring plus analogue analysis.

NetSocket, Inc. - Proprietary and Confidential

2-2

System Overview

2.4.1

SVA Standard IP MOS Monitoring

The SVA Standard IP MOS Monitoring configuration analyzes RTP streams for degradation that can be attributed directly to the IP network. The metrics are independently collected on each monitoring interface. The SVA calculates interval metric values every 30 seconds and at the end of the session. Cumulative metrics are also provided, which are calculated over the entire session. It is important to note that the interval and cumulative metrics are done independently. The cumulative metrics are not averages of the interval metrics. Cumulative metrics are also calculated for any Call Hold and Re-invite scenarios that occur following call establishment.

2.4.2

SVA IP MOS Plus Analogue

The SVA IP MOS Plus Analogue configuration analyzes both directions of the G.711 A-law and G.711 -law RTP streams associated with a call. Therefore, unlike the standard configuration, RTP streams for all configured interfaces are analyzed as a whole. Duplication of streams across multiple interfaces must be avoided so that accurate results can be calculated. In this configuration, the SVA reports the standard IP MOS monitoring metrics as well Signal to Noise and Echo. The reporting of the standard IP MOS monitoring metrics is the same as described in the SVA Standard IP MOS Monitoring section above. The Signal to Noise and Echo calculations are performed over a subset of the entire call according to the media analysis configuration command on the SVA. The results are reported as part of the cumulative IP MOS metrics.

2.5

SVM Dashboard
The SVM contains a web server to enable access to the SVM Dashboard using industry standard web browsers such as Firefox and Internet Explorer. The Dashboard can be accessed from any personal workstation within an operators network where the SVM is deployed. It presents information about the SVM-monitored domain in an easily understood and meaningful format and allows a user to run various searches and reports, while analyzing a network issue. The SVM Dashboard presents information about SVPs, SVAs and the operators network in both tabular and graphical formats.

NetSocket, Inc. - Proprietary and Confidential

2-3

Initial System Access

The SVM, SVP, and SVA systems are delivered with the NetSocket software installed but will need to be configured before they are placed in service. The systems are configured using a command line interface (CLI) which is typically accessed via SSH or Telnet using the IP address assigned to the management interface. However, during the initial configuration this interface will not have an IP address that is accessible on the management network. The following sections describe how to access the CLI using the default IP address, the serial ports, and a monitor and keyboard. The figures and table below show the connection points used to access the CLI using these three methods.

3.1

1U Server

Figure 3-1 - 1U Server Rear Panel Connection Points

Table 3-1 2U Server CLI Access Connection Points

Letter A B C D

Location Rear Panel Rear Panel Rear Panel Rear Panel

Description Serial port VGA connector USB ports Management interface (nnet0)

NetSocket, Inc. - Proprietary and Confidential

3-1

Initial System Access

3.2

2U Server

Figure 3-2 U2 Server Front Panel Connection Points

Figure 3-3 U2 Server Rear Panel Connection Points

Table 3-2 2U Server CLI Access Connection Points

Letter A B C D E F

Location Front Panel Front Panel Rear Panel Rear Panel Rear Panel Rear Panel

Description Serial port USB port Serial port VGA connector USB ports Management interface (nnet0)

3.3

CLI Access using the Default IP Address

The NetSocket systems ship with a default IP address of 192.168.0.1 and network mask of 255.255.255.0 configured on the management interface. To access the CLI using the default IP address, connect a PC or laptop directly to the management port using an Ethernet cable. The network interface on the PC or laptop should be configured with a static IP address of 192.168.0.2 and a network mask of 255.255.255.0. Once this interface has been configured the system will be reachable via SSH or Telnet using the IP address 192.168.0.1. Opening an SSH or Telnet connection to the default IP address will display the CLI login prompt. The default login credentials are username admin and password adminn.

NetSocket, Inc. - Proprietary and Confidential

3-2

Initial System Access

3.4
3.4.1

CLI Access using the Serial Ports

System Serial Ports
The 1U servers have a single serial port located on the rear panel. The 2U servers have two serial ports; one on the front panel and one at the rear panel. Connections can be made to either the front or the rear port. However, if the front panel serial port is used the rear serial port is deactivated. Both ports cannot be used at the same time. The serial ports have 8-pin RJ-45 connectors. The table below lists the pinout for the front and back panel serial port connectors.
Table 3-3 - Serial Port Pinout

Pin 1 2 3 4 5 6 7 8

Signal RTS (Request to Send) DTR (Data Terminal Ready) TXD (Transmit Data) GND RIA (Ring Indicator) RXD (Receive Data) DSR/DCD (Data set Ready / Data Carrier Detect CTS (Clear to Send)

To connect a PC to the system a RJ-45 to DB-9 adapter will be required. The pinout for this adapter is provided in the table below.
Table 3-4 - RJ-45 to DB-9 Adapter Pinout

SVM/SVP/SVA RJ-45 Serial Port Signal RTS DTR TXD GND RIA RXD DSR/DCD CTS Pin 1 2 3 4 5 6 7 8 Pin 8 6 2 5 5 3 4 7

PC DB-9 Serial Port Signal CTS DSR RXD GND GND TXD DTR RTS

The serial port on the NetSocket servers has the same pinouts as Cisco routers and switches. Therefore, console cables that can be used to connect to a Cisco device may also be used to connect to a NetSocket server. Note that the NetSocket serial port uses a higher baud rate than Cisco devices as shown in the table below.

NetSocket, Inc. - Proprietary and Confidential

3-3

Initial System Access

The following table provides the terminal settings used to connect to the serial ports.
Table 3-5 - Serial Port Terminal Settings

Setting Baud Rate Data Bits Parity Stop Bits Flow Control

Value 115200 8 None 1 RTS/CTS

3.4.2

Accessing the CLI from a Serial Port

After connecting to one of the serial ports, pressing the enter key will cause the system shell login prompt to be displayed. The default login credentials are username admin and password adminn. Once the shell prompt (%) is displayed, type cli to enter the CLI. The default username and password are also used to login to the CLI. At the initial CLI prompt (>) type enable to enter enable mode. By default, the console uses a terminal length of 25 lines. If you are using a terminal window with more than 25 lines, you will need to set the terminal length so the paging behaves properly. This can be accomplished using the terminal length <lines> CLI command.

3.5

CLI Access using a Monitor and Keyboard

The CLI can also be accessed using a monitor and USB keyboard. The monitor should be connected to the VGA connector on the rear panel. The USB keyboard can be connected to any of the USB connectors on the front or rear panels. After the keyboard is connected, pressing the enter key will cause the CLI login prompt to be displayed. The default login credentials are username admin and password adminn. At the initial CLI prompt (>) type enable to enter enable mode.

NetSocket, Inc. - Proprietary and Confidential

3-4

General System Configuration

When the system is delivered it may not contain information specific to the deployment site; specifically the system's IP address. Therefore, these commands may need to be issued using the console port connection. This chapter identifies the initial configuration steps common to the SVM, SVP, and SVA. The information is presented according to configuration tasks. The first section of the chapter gives an example configuration. The syntax for the CLI commands used in the example configurations are defined in the SVSS Command Reference document. Note that the configuration changes will not be persistent across a system reboot until the configuration is saved using the copy running-config startup-config command.

4.1

System Configuration Example

This section contains configuration necessary for initial turn-up of the SVM, SVP, and SVA.

Figure 4-1 - System Configuration Example Network

NetSocket, Inc. - Proprietary and Confidential

4-1

General System Configuration

4.1.1

General Configuration
Commands The table below lists the commands used for general system configuration. Command clock summer-time clock timezone hostname interface ip address ip domain-name ip name-server ip route ntp server rcp-reboot rcp-shutdown speed sv-config username Description Configure daylight savings time Configure the time zone Configuration hostname Configure interface settings. Configure interface IP address. Sets the default domain name. Sets the domain name server. Provisions static route as needed for connectivity. Provisions the system to get its timing from an NTP server Reboot the system so that SV specific configuration takes effect. Shuts the system down and powers it off Configure interface speed (optional) Provision SV specific server configuration. Provisions user accounts for CLI and Web only access.

Configuration Example The example below shows the general configuration on the SVM shown in the System Configuration Example Network above: The SV config is set to indicate the server performs the SVM function in a VoIP deployment. The hostname is set to SVM1. The system is configured to lookup domain names using a DNS server at 192.168.1.9. Three user accounts are configured, the CLI admin account, a GUI admin account, and a standard GUI user account. The user accounts created using the gui keyword cannot be used to login to the SVM CLI. The GUI admin account is set to privilege level 15 and will enable the user to access the admin functionality in the SVM Dashboard. An IP address is configured on nnet0, the management interface. The interface speed is set purely as an example. This is only required for nnet0 or em interfaces when connected to an interface not running at gigabit speed. A default route is added to the SVM to route traffic to the default gateway on the management network. The system is configured to get its timing from an NTP server at 192.168.1.8

NetSocket, Inc. - Proprietary and Confidential

4-2

General System Configuration

The time zone is set to Central Standard Time (CST) which is -6 hours from UTC Daylight savings time is set to Central Daylight Time (CDT) which starts at 2:00 am on th th March 11 2012 and ends at 2:00 on November 4 2012.

sv-config sv-type svm deployment-type voip ! configure terminal ! hostname SVM1 ! ip domain-name netsocket.com ip name-server 192.168.1.9 ! username admin password clipassword username guiadmin privilege 15 password guipassword gui username guiuser password userpassword gui ! interface nnet0 ip address 192.168.1.2/24 speed 1000 exit ! ip route 0.0.0.0 0.0.0.0 192.168.1.1 ! ntp server 192.168.1.8 ! clock timezone CST -6 ! clock summer-time CDT date Mar 11 2012 02:00 Nov 04 2012 02:00 60 ! end ! copy running-config startup-config ! rcp-reboot now Note: The general configuration for the SVP and SVA are the same as the example above, however, the SVP and SVA do not require GUI users to be configured. Note: To function properly, the timing on the SVM must be synchronized with all monitored SVPs and SVAs as well as the computer running the web browser connected to the SVM Dashboard. It is recommended that all systems get timing from a common NTP server as shown in the example above. An alert will be declared via the SVM if any monitored SVP or SVA is not synchronized. Note: The reboot is required in order for the SV configuration to take effect.

NetSocket, Inc. - Proprietary and Confidential

4-3

General System Configuration

4.1.2

TACACS Configuration
The previous section showed how to configure the CLI and user accounts using the local database. TACACS can be configured as the primary means for user authentication and authorization. The local database can be used in the event that the TACACS server is unavailable. As discussed above there are two types of accounts: CLI accounts and GUI accounts. The authorization for CLI accounts must be specified in the TACACS configuration file. The GUI accounts should not be given any authorization. This will allow them to be authenticated by the WEB server and will prohibit them from using the CLI. The GUI administrator account still requires being entered via the CLI since the WEB server requires a local database to distinguish this user from other GUI users. However, the password authentication will still be done via TACACS. Also it is suggested that the CLI administrator account be provisioned locally in case the TACACS service is unavailable. Note: The tacacs-server command could use the server name instead of an IP address as shown in the example to allow for redundancy in the event of failures. The username commands below replace the username commands in the previous example. Commands Command aaa authentication login aaa authorization exec aaa new-model tacacs-server host username Description Configures the SV node to authentication for user logins. Creates the default EXEC authorization list. Enables creation of the aaa authentication and authorization. Configure TACACS server and encryption key. Provisions user accounts for CLI and Web only access.

Configuration Example The example below shows the general configuration on the SVM.

NetSocket, Inc. - Proprietary and Confidential

4-4

General System Configuration

configure terminal ! username admin password clipassword username guiadmin privilege 15 password guipassword gui ! tacacs-server host 192.168.1.10 key cle_tacacs ! aaa new-model aaa authentication login default tacacs+ local aaa authorization exec default tacacs+ local end copy running-config startup-config NOTE: the addition of local keyword following tacacs+ allows the SVM to use the local database in the event that communication with the TACACS server is down. TACACS Configuration File Example The example below shows the general configuration on the TACACS server. # tacacs configuration file # set the key to match SVMtacacs key key = cle_tacacs # CLI admin account user = admin { default service = permit login = cleartextclipassword } # GUI admin account required for authentication no authorization user = guiadmin { default service = deny login = cleartextguipassword } # Additional gui user only entered here not in CLI user = guiuser { default service = deny login = cleartextuserpassword }

NetSocket, Inc. - Proprietary and Confidential

4-5

General System Configuration

4.1.3

Maintenance Window Configuration

The system performs daily maintenance activities. This command configures the time this activity should be performed and should coincide periods the network activity is expected to be light. Commands Command maintenance-window Description Provision daily time period monitored network is expected to be quiescent.

Configuration Example The following example configures the maintenance window to be between 2:15 am and 3:15 am. configure terminal maintenance-window start-time 02:15 end-time 03:15 end copy running-config startup-config

4.1.4

Host Login Lockout Resolution

User login via telnet and SSH are monitored to thwart access by unauthorized personnel. If six consecutive login failures are detected from the same host machine, the system will lockout subsequent login connections from that IP address. The lockout persists until cleared via a CLI command. Commands Command show host-login-lockout clear host-login-lockout Command Example The following example demonstrates how these commands can be used to clear a lockout. show host-login-lockout 10.0.0.5 4 consecutive failures 10.0.0.6 locked out clear host-login-lockout 10.0.0.6 Description Command displays host IPs that have been locked out from further access. Clear lockout for host.

NetSocket, Inc. - Proprietary and Confidential

4-6

SVP Configuration
This chapter identifies the configuration steps used to provision a Service Visibility Point. The information is presented according to configuration tasks. Remember that the configuration changes will not be persistent across a system reboot until the configuration is saved using the copy running-config startup-config command.

5.1

SVP Configuration Example Network

The example network below is used to show the configuration steps specific to the SVP.

Figure 5-1 - SVP Configuration Example Network

NetSocket, Inc. - Proprietary and Confidential

5-1

SVPConfiguration

5.2

SVP License
Before an SVP is able to monitor sessions and routers in the network a license must be obtained from NetSocket and provisioned with the following command. Commands Command rcp license-key Description NetSocket provided license to enable session and router monitoring.

Configuration Example The following example configures the SVP with a license key. configure terminal rcp license-key OAIG-ICML-GIEGCOKK-JMAN-NFPN-PBBE-MNOP end copy running-config startup-config

5.3

SVA Monitoring
Commands The table below lists the commands necessary to configure an SVP to monitor one or more SVAs. Command rcp monitor Description Provision the SVP to connect to an SVA that receives media traffic from router interface in the SVP monitored network.

Configuration Example The following example configures the SVP monitor an SVA with the IP address 192.168.1.4 as shown in the SVP Configuration Example Network above. configure terminal rcp monitor rcpa-ip-address192.168.1.4 end copy running-config startup-config

NetSocket, Inc. - Proprietary and Confidential

5-2

6
6.1

SVP Session Monitoring Configuration

Session Signaling Monitoring Interface Configuration
The SVP can be configured to monitor session signaling in an enterprise deployment. The relevant commands are listed in the table below. Commands Command session-capture Description Enable session signaling message capture for the specified interface

Configuration Example The following example shows the configuration necessary to enable the SVP to monitor the following: SIP sessions on ports 5060 and 5061 on the first monitoring interface (xyxs0) H323 sessions on the second monitoring interface (xyxs1) UNIStim sessions on port 5000 on the third monitoring interface (xyxs2) configure terminal ! session-capture interface xyxs0 direction both ingress-port 5060 message-filter sip ! session-capture interface xyxs0 direction both ingress-port 5061 message-filter sip ! session-capture interface xyxs1 direction both message-filter h323 ! session-capture interface xyxs2 direction both ingress-port 5000 message-filter unistim profile-name acc1 ! end copy running-config startup-config

NetSocket, Inc. - Proprietary and Confidential

6-1

SVP Session Monitoring Configuration

6.2

Session Signaling Monitoring Options

Commands Command session-delay-success session-from-id session-timeout session-pcap-ratio Description Delay determination of successful session for some number of seconds. Specify what field should be used for the session from Id. Specify the session setup and established timeouts. Specify the ratio of successful sessions to capture pcap messages for. See usage notes in the command description.

Configuration Example The following example shows the configuration commands used to tune parameters of the SVP with respect to how it captures sessions: Session success or failure will be determined 3 seconds after completion of signaling. Sessions captured are to use the SIP contact-ID field for session records vs. the default setting of using the SIP from-ID field. Signaling messages for 100% of successfully established sessions are to be captured..Note: Signaling messages for 100% of unsuccessfully established sessions are always captured regardless of the session-pcap-ratio setting. Sessions are expected to setup within 45 seconds (typical ringing time), and not be established for more than 1800 seconds without a keep alive. configure terminal ! session-delay-success 3 session-pcap-ratio 100 session-from-id sip contact-id session-timeout setup 45 established 1800 ! end copy running-config startup-config

NetSocket, Inc. - Proprietary and Confidential

6-2

SVP Network Monitoring Configuration

This chapter identifies the configuration steps and CLI commands used to provision a Service Visibility Point to monitor an IP routed network. The information is presented according to configuration tasks. The first section of the document shows an example network that is referenced throughout the document. The syntax for the CLI commands used in the example configurations are defined in the SVSS Command Reference document. An SVP monitors the IP network as follows: OSPF The SVP establishes a neighbor relationship with a router in the SVP-monitored domain to learn the OSPF routing table for the routers. The SVP does not introduce any updates or traffic into the network through this peering relationship. BGP The SVP establishes an iBGP peering relationship with each router in the SVPmonitored domain to learn the BGP routing table for the routers. The SVP does not introduce any updates or traffic into the network through this peering relationship. SNMP Polling The SVP uses read-only SNMP access to poll the monitored routers for interface information, QoS statistics, MPLS-TE tunnel information, and the route table. The interface information polling is mandatory. All other SNMP polling is optional and is enabled via separate configuration commands. CLI Polling The SVP uses level 0 CLI access to learn static routes configured on the monitored routers. The CLI polling is optional and is only required when the routers are configured with static routes. NetFlow Statistics This allows a router configured with NetFlow version 5 or 9 (or Jflow) to send its statistical information to the configured port on the SVP, where it is collected. Note: The configuration changes will not be persistent across a system reboot until the configuration is saved using the copy running-config startup-config command.

NetSocket, Inc. - Proprietary and Confidential

7-1

SVP Network Monitoring Configuration

7.1
7.1.1

Complete Example Configurations

SVP Configuration Example
The following example configuration shows an SVP provisioned to monitor two routers as seen in the SVP Configuration Example Network in the SVP Configuration chapter: IP address 192.168.100.1/30 is configured on the em0 interface which is connected to router R1 A topology-map named DWFDC is created OSPF is enabled on the em0 interface. The OSPF process id is 1 and the area is 0. BGP peering is configured with both routers using their loopback addresses 1.0.0.1 and 1.0.0.2 and AS 100. Read-only SNMP v2c polling is configured for the two routers using community string netsocket Read-only CLI polling is configured for the two routers using username netsocket and password nspass Collection of HSRP information for the two routers is enabled The SVP is configured to collect EIGRP routes using route table polling The SVP is configured to collect load distribution information from the two routers The SVP is provisioned to receive and process SNMP v2c link state traps from the two routers

NetSocket, Inc. - Proprietary and Confidential

7-2

SVP Network Monitoring Configuration

configure terminal ! interface em0 ip address 192.168.100.1/30 ip ospf database-filter all out ! snmp-trap-receive udp-port 162 trigger-route-polling 15 ! topology-map DFWDC ospf-topology-neighbor em0 area 0 ospf-id 1 ! bgp-topology-neighbor 1.0.0.1 as-num 100 bgp-topology-neighbor 1.0.0.2 as-num 100 ! router 1.0.0.1 snmp-access host 1.0.0.1 version 2c community netsocket interval 60 cli-access host 1.0.0.1 username netsocket password nspass interval 120 hsrp-mib route-table-poll eigrp load-distribution cef snmp-trap-source version 2c community netsocket exit router 1.0.0.2 snmp-access host 1.0.0.2 version 2c community netsocket interval 60 cli-access host 1.0.0.2 username netsocket password nspass interval 120 hsrp-mib route-table-poll eigrp load-distribution cef snmp-trap-source version 2c community netsocket exit end ! copy running-config startup-config

Note: The SNMP community strings in the snmp-access and snmp-trap-source commands and the CLI password in the cli-access command will be encrypted after being entered and will not show up in the running-config in clear text as shown above.

NetSocket, Inc. - Proprietary and Confidential

7-3

SVP Network Monitoring Configuration

7.1.2

Cisco Router Configuration Example

The following example configuration shows the commands used on a Cisco router to allow it to be monitored by the SVP in the example above: A read-only (privilege level 0) CLI login is setup for the SVP using username netsocket and password nspass The g0/0 interface is configured and an OSPF adjacency with the SVP is provisioned over it An iBGP peer is provisioned with the SVP Read-only SNMP access using v2c is configured for the SVP The router is configured to send link event SNMP traps to the SVP
configure terminal ! username netsocket privilege 0 password nspass ! interface Loopback0 ip address 1.0.0.1 255.255.255.255 ! interface g0/0 ip address 192.168.100.2 255.255.255.252 ! router ospf 1 network 192.168.100.0 0.0.0.3 area 0 ! router bgp 100 neighbor 192.168.100.1 remote-as 100 neighbor 192.168.100.1 update-source Loopback0 neighbor 192.168.100.1 route-reflector-client ! snmp-server community netsocket RO ! snmp-server trap-source Loopback0 snmp-server enable traps snmp linkdown linkup snmp-server host 192.168.100.1 version 2c netsocketsnmp ! line vty 0 4 login local ! end ! copy running-config startup-config

NetSocket, Inc. - Proprietary and Confidential

7-4

SVP Network Monitoring Configuration

7.2

Topology Map Configuration

A topology map that defines the routers and layer 3 switches being monitored must first be created on the SVP. The commands required to define this map are listed below. Commands Command topology-map Configuration Example The following commands will configure a topology map named DFWDC on an SVP:
configure terminal ! topology-map DFWCD end copy running-config startup-config

Description Configure topology map to specify monitored network.

7.3

Router Configuration
Once the topology map has been defined, the routers that will be monitored must be added to this map. The set of commands required to add routers to the map and complete the configuration are listed below. Commands Command cli-access host load-distribution hsrp-mib router route-table-poll snmp-access host snmp-trap-receive snmp-trap-source Description CLI login information required to retrieve additional information for maintaining router DRIB. Enable collection of load-distribution algorithm information. Collection information from pairs of routers regarding HSRP state. Identification of router to be monitored for topology map. Enable collection of BGP multi-path routes to override route obtained from peering. Configure SNMP information to access information required for maintaining router DRIB in topology map. Configure the SVP to open a listen port to receive snmp link state traps from the routers it is monitoring. Allow traps from a given router to be processed.

NetSocket, Inc. - Proprietary and Confidential

7-5

SVP Network Monitoring Configuration

topology-map vrrp-mib

Configure topology map to specify monitored network. Collection information from pairs of routers regarding VRRP state.

7.3.1

Adding a Router
A router is added using the router CLI command in the topology-map configuration mode. The command takes an IP address as an input parameter that will be used to identify the router in the SVM Dashboard. This IP address is usually set to the routers loopback 0 IP address. Configuration Example The following commands will add two routers to the MLFC topology map:
configure terminal ! topology-map DFWCD router 1.0.0.1 exit router 1.0.0.2 exit end copy running-config startup-config

7.3.2

Configuring SNMP Read-Only Access to the Routers

The SVP uses SNMP read-only access to learn the monitored routers hostnames, interface names, interface IP addresses, and interface states. The SVP can also be configured to use the SNMP access to collect interface and QoS statistics. The SVP supports SNMP v1, v2c, and v3. Configuration Example The following commands will configure SNMP read-only access for the two routers added in the section above:
configure terminal ! topology-map DFWCD router 1.0.0.1 snmp-access host 1.0.0.1 version 2c community netsocket interval 60 exit router 1.0.0.2 snmp-access host 1.0.0.2 version 2c community netsocket interval 60 exit end copy running-config startup-config

NetSocket, Inc. - Proprietary and Confidential

7-6

SVP Network Monitoring Configuration

Note: The SNMP community string in the snmp-access command will be encrypted after being entered and will not show up in the running-config in clear text as shown above. The configuration commands used on the R1 router are shown below:
configure terminal ! snmp-server community netsocket RO ! end copy running-config startup-config

Note: An access-list could be used on the router to limit the SNMP access to the SVPs nnet0 IP address.

7.3.3

Configuring CLI Read-Only Access to the Routers

The SVP uses CLI read-only (privilege level 0) access to learn static route information from the monitored routers. CLI polling is also used to collect the full route table when a link state routing protocol is not in use in the network. The SVP supports connecting to the routers CLI via Telnet and SSH. Only a few show commands are sent to the router so the SVP does not require access to privileged exec mode. Configuration Example The following commands will configure CLI read-only access for the two routers added in the section above:
configure terminal ! topology-map DFWCD router 1.0.0.1 cli-access host 1.0.0.1 username netsocket password nspass interval 60 exit router 1.0.0.2 cli-access host 1.0.0.2 username netsocket password nspass interval 60 exit end copy running-config startup-config

Note: The CLI password in the cli-access command will be encrypted after being entered and will not show up in the running-config in clear text as shown above. The configuration commands used on the R1 router are shown below:

NetSocket, Inc. - Proprietary and Confidential

7-7

SVP Network Monitoring Configuration

configure terminal ! username netsocket privilege 0 password nspass ! line vty 0 4 login local ! end copy running-config startup-config

7.3.4

Configuring Route Table Polling

The SVP can optionally be configured to poll the route tables of the routers it is monitoring using the routers CLI. This capability may be used when peering with the router is not desirable; for example, when EIGRP is used as the IGP. Note 1: If IGPs other than EIGRP are used, then it is recommended that the user enable the SVP peering using that protocol (see Section 1.4). Note 2: This command has no effect if the cli-access host command is not enabled. Configuration Example The following example configures the SVP to retrieve EIGRP routes by polling the route table of the two routers in the example network. Note: The route table is polled using CLI. Therefore cli access must be configured.
configure terminal ! topology-map DFWCD router 1.0.0.1 route-table-poll eigrp exit router 1.0.0.2 route-table-poll eigrp exit end copy running-config startup-config

NetSocket, Inc. - Proprietary and Confidential

7-8

SVP Network Monitoring Configuration

7.3.5

Configuring Load Distribution Polling

The SVP can be configured to collect load distribution information from its monitored routers. This allows the SVP to select the correct outbound interface for sessions in networks with multiple equal cost routes. Load distribution polling is configured on the SVPs on a per router basis. Once provisioned, the SVPs use CLI access to collect the load distribution information. Therefore CLI access must be configured. Configuration Example The following example configures the SVP to collect load distribution information from the two routers in the example network.
configure terminal ! topology-map DFWCD router 1.0.0.1 load-distribution cef exit router 1.0.0.2 load-distribution cef exit end copy running-config startup-config

7.3.6

Configuring QoS Statistics Polling

The SVP can be configured to poll the routers that it monitors for Quality of Service (QoS) counters. Currently the NetSocket Service Visibility Solution Suite supports QoS polling from Cisco routers provisioned with Class-Based Weighted Fair Queuing (CBWFQ), Class-Based Weighted Fair Queuing with Low Latency Queuing (LLQ), or Weighted Round Robin (WRR). QoS polling is configured on the SVPs on a per router basis. Once provisioned, the SVPs use SNMP to poll the routers at a user specified polling interval. The SVPs will poll and store QoS data for each interface on the provisioned routers that have a supported QoS policy defined. Configuration Example The following example configures the SVP to poll QoS statistics from the two routers in the example network.

NetSocket, Inc. - Proprietary and Confidential

7-9

SVP Network Monitoring Configuration

configure terminal ! topology-map DFWCD router 1.0.0.1 qos-mib max-queues 8 exit router 1.0.0.2 qos-mib max-queues 8 exit end copy running-config startup-config

7.3.7

Configuring NetFlow / Jflow Statistical Collection

The SVP can be configured to accept and collect a routers transmitted NetFlow statistical information. It collects this and therefore allows monitoring and aggregation of the data. Currently the NetSocket Service Visibility Solution Suite supports NetFlow messaging from Cisco routers provisioned with NetFlow versions 5 or 9, or Juniper routers configured with Jflow. NetFlow collection must first be enabled on the SVP using the netflow-collection command in global configuration mode. Once provisioned, the SVPs open the configured port to listen for Netflow messages. Processing of NetFlow messages received from a router must be enabled within thats router configuration of the topology map configuration mode. Messages received from routers that are not enabled will be discarded. Configuration Example The following example configures the SVP to allow NetFlow statistics from the two routers in the example network.
configure terminal ! netflow-collection udp-port1 9996 aggregation-limit 20 flow-record no-aggregation ! topology-map DFWCD router 1.0.0.1 netflow-receive ip-address 1.0.0.1 template-timeout 35 exit router 1.0.0.2 netflow-receive ip-address 1.0.0.2 template-timeout 35 exit end copy running-config startup-config

The following example configures a Cisco router to send its NetFlow statistical data for certain interfaces towards the SVP:

NetSocket, Inc. - Proprietary and Confidential

7-10

SVP Network Monitoring Configuration

configure terminal ! ip flow-cache timeout active 1 ! ip flow-export source Loopback0 ip flow-export version 9 ip flow-export destination 192.168.100.1 9996 ! interface FastEthernet1/0 ip route-cache flow exit ! interface FastEthernet1/1 ip route-cache flow exit ! exit copy running-config startup-config

7.3.8

Configuring First Hop Router Redundancy Polling

The SVP can be configured to poll the routers to learn VRRP and HSRP state information. This allows the SVP to select the correct inbound interface for sessions using the virtual IP advertised by VRRP and HSRP. VRRP and HSRP polling is configured on the SVPs on a per router basis. Once provisioned, the SVPs use SNMP poll the routers at a user specified polling interval. Configuration Example The following example configures the SVP to poll HSRP information from the two routers in the example network.
configure terminal ! topology-map DFWCD router 1.0.0.1 hsrp-mib exit router 1.0.0.2 hsrp-mib exit end copy running-config startup-config

NetSocket, Inc. - Proprietary and Confidential

7-11

SVP Network Monitoring Configuration

7.3.9

Configuring Routers to Send SNMP Traps to the SVP

The monitored routers can be configured to send SNMP traps to the SVP when they have an interface state change. This allows the SVP to have accurate timestamps for network changes without the need for a short polling interval. Configuration Example The following commands will configure the SVP to receive SNMP traps from the two routers in the example network:
configure terminal ! snmp-trap-receive udp-port 162 trigger-route-polling 15 ! topology-map DFWCD router 1.0.0.1 snmp-trap-source version 2c community netsocket exit router 1.0.0.2 snmp-trap-source version 2c community netsocket exit end copy running-config startup-config

Note: The SNMP community string in the snmp-trap-source command will be encrypted after being entered and will not show up in the running-config in clear text as shown above. The configuration commands used on the R1 router are shown below:
configure terminal ! snmp-server trap-source Loopback0 snmp-server enable traps snmp linkdown linkup snmp-server host 192.168.100.1 version 2c public snmp ! end copy running-config startup-config

NetSocket, Inc. - Proprietary and Confidential

7-12

SVP Network Monitoring Configuration

7.4

SVP Router Peering Configuration

The SVP has the ability to natively peer with a monitored router to learn real-time routing information using IGP/EGP protocols. The commands used to configure router peering are shown in the table below. Commands Command bgp-topology-neighbor ospf-topology-neighbor Description BGP neighbor configuration required for maintaining router DRIB. OSPF neighbor information required for establishing neighbor relationship needed to construct topology map.

7.4.1

OSPF Configuration
The SVP can form a neighbor relationship with a monitored router in order to learn real-time routing data via OSPF. The OSPF adjacency requires a direct layer 3 connection between the router and the SVP. Configuration Example The following example configures the following: An IP address on the em0 interface which is connected to the R1 router Configures OSPF on em0 in area 0
configure terminal ! interface em0 ip address 192.168.100.1/30 ipospf database-filter all out ! topology-map DFWCD ospf-topology-neighbor em0 area 0 ospf-id 1 end copy running-config startup-config

The configuration commands used on the R1 router are shown below:

NetSocket, Inc. - Proprietary and Confidential

7-13

SVP Network Monitoring Configuration

configure terminal ! interface Loopback0 ip address 1.0.0.1 255.255.255.255 ! interface g0/0 ip address 192.168.100.2 255.255.255.252 ! router ospf 1 network 192.168.100.0 0.0.0.3 area 0 ! end copy running-config startup-config

7.4.2

BGP Configuration
The SVP can form iBGP peering relationships with monitored routers in order to learn real-time routing data via BGP. In order to collect all BGP information the SVP needs to peer with each monitored router that is running BGP. Configuration Example The following example configures an iBGP peering relationship with the two routers in the example network.
configure terminal ! topology-map DFWCD bgp-topology-neighbor 1.0.0.1 as-num 100 bgp-topology-neighbor 1.0.0.2 as-num 100 end copy running-config startup-config

The configuration commands used on the R1 router are shown below:

configure terminal ! interface Loopback0 ip address 1.0.0.1 255.255.255.255 ! router bgp 100 neighbor 192.168.100.1 remote-as 100 neighbor 192.168.100.1 update-source Loopback0 neighbor 192.168.100.1 route-reflector-client ! end copy running-config startup-config

Note: The neighbor route-reflector-client command is required so that the router sends the SVP its complete BGP information.

NetSocket, Inc. - Proprietary and Confidential

7-14

SVP Threshold Configuration

There are 3 main types of thresholds that can be configured on an SVP: Link based thresholds Generates alerts based on link level conditions Session path based thresholds Generated alerts based on network events that affect the routing of the session media packets peering Session based thresholds Generates alerts based on the Key Performance Indicators (KPI) calculated by the SVP Note that the threshold configuration can be tuned on a per-SVP basis, which is important for customers with multiple SVPs implemented.

8.1

Link Based Thresholds

The SVP can be configured to generate alerts based on link level conditions such as congestion and packet drops. The commands required to enable this feature are listed below. Commands Command link-bandwidth threshold link-bandwidth utilization threshold link-packet-drop threshold queue-bandwidth-utilization Configuration Example The following example configures link based thresholds on the SVP.
configure terminal ! link-bandwidth thresholds set-threshold 60 clear-threshold 50 ! link-bandwidth utilization thresholds set-threshold 80 clear-threshold 75 ! link-packet-drop thresholds set-threshold 20000 clear-threshold 10000 ! queue-bandwidth-utilization thresholds priority-set 90 priority-clear 80 ! end copy running-config startup-config

Description Link bandwidth threshold for session reserved bandwidth. Link bandwidth threshold for actual link utilization retrieved from interface counts. Link threshold for reporting excessive packet drops. Link threshold for QoS queue bandwidth utilization

NetSocket, Inc. - Proprietary and Confidential

8-1

SVP Threshold Configuration

8.2

Session Path Based Thresholds

Commands The SVP can be configured to generate alerts based on network events that affect the routing of the session media packets. There are two sets of alerts: SVP system wide: considers all sessions monitored by the SVP Link based: considers the previous and/or current session path to isolate problem to a specific router interface. The first set of alerts is course grained to indicate a general problem. The second set of alerts isolate the problem using a per session path analysis. The commands required to enable these feature are listed in the table below. Command session-loop-alert Command parameter thresholds Description System threshold to detect excessive number of sessions affected by routing loop. Link level threshold to detect excessive number of sessions affected by routing loop. System threshold to detect excessive number of sessions for which a path from source to destination is not found. Link threshold to detect excessive number of sessions for which a path from source to destination is not found. System threshold to detect excessive number of sessions that have experienced one or more path changes. Link threshold to detect excessive number of sessions that have experienced a path changes from a given link.

session-loop-alert

link-thresholds

session-noroute-alert

thresholds

session-noroute-alert

link-thresholds

session-unstable-alert

thresholds

session-unstable-alert

link-thresholds

NetSocket, Inc. - Proprietary and Confidential

8-2

SVP Threshold Configuration

Configuration Example The following example configures session path thresholds on the SVP.
configure terminal ! session-loop-alert thresholds set-threshold 25 clear-threshold 20 ! session-noroute-alert thresholds set-threshold 20 clear-threshold 10 ! session-unstable-alert thresholds set-threshold 100 clear-threshold 80 ! end copy running-config startup-config

8.3

Session Based Thresholds

The SVP can be configured to alert on session thresholds. These thresholds are based on the KPI calculated by the SVP. The relevant commands are listed in the table below. Session-threshold Configuration Mode Commands Command interval-start-time minimum-sessions Description Start time for threshold intervals Sets the minimum number of sessions that must be active before a session based alert will be declared. The default is 20 sessions. Configure thresholds for generating alerts related to KPI counters.

session-thresholds

Signaling KPI Based CLI Commands Command aar acd acdd apdd ard avd avdd avpdd ccsr Description Average Active Registrations threshold Average Call Duration threshold Average Call Disconnect Delay threshold Average Post Dial Delay threshold Average Registration Delay threshold Average Video Duration threshold Average Video Disconnect Delay threshold Average Video Post Dial Delay threshold Call Circuit Success Ratio threshold

NetSocket, Inc. - Proprietary and Confidential

8-3

SVP Threshold Configuration

nar rsr vsr

Network Availability threshold Registration Success Ratio threshold. Video Success Ratio threshold

Media KPI Based CLI Commands Command bmosp fmosp gmosp mmp pdsp plsp pmosp snrsp uersp Description Bad MOS Percentage threshold Fair MOS Percentage threshold Good MOS Percentage threshold Missing Media Percentage threshold Packet Drop Session Percentage threshold Packet Loss Session Percentage threshold Poor MOS Percentage threshold Signal to Noise Ratio Session Percentage threshold Unacceptable Echo Rating Session Percentage threshold

Configuration Example The following example configures: Four session threshold intervals o Interval 1: 12:00 am to 5:59 am o Interval 2: 6:00 am to 11:59 am o Interval 3: 12:00 pm to 5:59 pm o Interval 4: 6:00 pm to 11:59 pm Minimum Session Count for alert declaration. o Interval 1: 20 sessions (default) in alert detection period must occur. o Interval 2: 15 sessions in alert detection period must occur. o Interval 3: Any sessions in alert detection period. o Interval4: 20 sessions (default) in alert detection period must occur. The Call Connect Success Ratio threshold o Interval 1: Sets when the ratio is less the 75%, clears when it rises above 80% o Interval 2: Not configured, CCSR alert will not be declared during this interval o Interval 3: Not configured, CCSR alert will not be declared during this interval o Interval 4: Sets when the ratio is less the 60%, clears when it rises above 70% The Bad MOS Session Percentage threshold o Interval 1: Not configured, BMOSP alert will not be declared during this interval o Interval 2: Sets when the percentage is more than10%, clears when it goes below 5% o Interval 3: Sets when the percentage is more than20%, clears when it goes

NetSocket, Inc. - Proprietary and Confidential

8-4

SVP Threshold Configuration

below 10% Interval 4: Not configured, BMOSP alert will not be declared during this interval

configure terminal ! session-thresholds interval-start-time time1 00 time2 06 time3 12 time4 18 minimum-sessions interval2 15 interval3 1 ccsr interval1 set 75 clear 80 interval4 set 60 clear 70 bmosp interval2 set 10 clear 5 interval3 set 20 clear 10 ! end copy running-config startup-config

NetSocket, Inc. - Proprietary and Confidential

8-5

9
9.1

SVP Network Security Configuration

SVP Network Services
The SVP can be provisioned to act as a server for the following network services: FTP SSH Telnet By default, only the SSH and Telnet servers are enabled. Commands Command enable service no enable service Configuration Example The following example disables the Telnet service. configure terminal ! no enable service telnet ! end copy running-config startup-config Enables a service Disabled a service Description

9.2
9.2.1

SVP Interface Security

SVP EM Interface Security
SVP to Managed Router Protocols The table below shows the protocols that the SVP uses to communicate with routers provisioned in the topology-map. Protocol Telnet SSH SNMP CLI Command to enable cli-access cli-access snmp-access Transport Protocol TCP TCP UDP Source Port 23 22 161 Dest Port any any any

NetSocket, Inc. - Proprietary and Confidential

9-1

SVP Network Security Configuration

OSPF BGP

ospf-topology-neighbor bgp-topology-neighbor

89 TCP

179

any

Access-List Rules The following rules are used to configure an access-list to block all unnecessary incoming traffic on the EM Interfaces: ICMP Ping Allow outgoing ping (ICMP echo request) access-listemIn permit icmp any any echo Allow incoming ping response (ICMP echo reply) access-listemIn permit icmp any any echo-reply

OSPF (Protocol 89) Allow OSPF packets Should be added when the first ospf-topology-neighbor is entered. Should be removed when the last ospf-topology-neighbor is removed. access-listemIn permit ospf any any Router Access BGP (TCP 179) Should be added/Removed when the bgp-topology-neighbor command is provisioned One line needed for each bgp-topology-neighbor command access-listemIn permit tcp host <router-ip>eq 179 any SNMP (UDP 161) Should be added/Removed when the snmp-access command is provisioned (port can change if udp-port option used) One line needed for each snmp-access command access-listemIn permit udp host <router-ip>eq 161 any SSH (TCP 22) Should be added/Removed when the cli-access command is provisioned with access-type ssh One line needed for each cli-access command with the access-type ssh option access-listemIn permit tcp host <router-ip>eq 22 any Telnet (SVP 23) Should be added/Removed when the cli-access command is provisioned with access-type telnet (default) One line needed for each cli-access command without the access-type ssh option

NetSocket, Inc. - Proprietary and Confidential

9-2

SVP Network Security Configuration

access-listemIn permit tcp host <router-ip>eq 23 any Implicit Deny All at end of access-list blocks all other traffic

Commands Command access-list ip access-group Defines an access-list Applies an access list to an interface Description

Configuration Example The following commands configure an access-list to only allow communication with the routers defined in the topology-map in the SVP Network Monitoring Configuration section: configure terminal ! access-list emIn permit icmp any any echo access-list emIn permit icmp any any echo-reply ! access-list emIn permit ospf any any ! access-list emIn permit tcp host 1.0.0.1 eq 179 any access-list emIn permit udp host 1.0.0.1 eq 161 any access-list emIn permit tcp host 1.0.0.1 eq 23 any ! access-list emIn permit tcp host 1.0.0.2 eq 179 any access-list emIn permit udp host 1.0.0.2 eq 161 any access-list emIn permit tcp host 1.0.0.2 eq 23 any ! end copy running-config startup-config

The following commands apply the access-list emIn to em0, the interface connected to the network in the SVP Configuration Example Network: configure terminal ! interface em0 ip access-group emIn in ! end copy running-config startup-config

NetSocket, Inc. - Proprietary and Confidential

9-3

10 SVP Show and Debug Commands

The SVM Dashboard is intended to be the tool of choice for monitoring the network and the SVP(s). In some cases it may be necessary to retrieve information directly from the SVP using the CLI. This section contains a list of the most useful show and debug commands that can be executed on the SVP. Commands Command clear rcp statistics show link events router show link events current show rcm discovery show rcp alerts show rcp license show topology drib show topology interfaces show topology ospf show topology ospf interface show topology rib show topology route Description Test command to clear SVP statistics. Show alerts generated by SVP for specific router link. Show list of currently set alerts. Debug command to show internal router discovery state. Show SVP historical alerts. Show details of currently installed license. Show topology map DRIB contents. Show interfaces discovered in topology map. Show topology map OSPF status. Show topology map interface state derived from OSPF. Show the RIB information for a DRIB. Show route contained in DRIB.

NetSocket, Inc. - Proprietary and Confidential

10-1

NetSocket, Inc. - Proprietary and Confidential