Professional Documents
Culture Documents
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 APPLICATION 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 INFOR MATION 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 SUITABILITY 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
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
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
SVM Configuration .................................................................................................................... 5-1 5.1 5.2 5.3 5.4 5.5 SVP Monitoring ................................................................................................................ 5-1 Web Server Configuration ............................................................................................... 5-1 Alert Notification via SNMP Traps ................................................................................... 5-2 Alert Notification via E-mail.............................................................................................. 5-3 Software Upgrade ............................................................................................................ 5-4
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
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
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.
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).
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.
2-2
System Overview
2.4.1
2.4.2
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.
2-3
3.1
1U Server
Letter A B C D
Description Serial port VGA connector USB ports Management interface (nnet0)
3-1
3.2
2U Server
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
3-2
3.4
3.4.1
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.
3-3
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
3.4.2
3.5
3-4
4.1
4-1
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
4-2
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.
4-3
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.
4-4
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 }
4-5
4.1.3
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
4-6
5
5.1
SVM Configuration
SVP Monitoring
The SVM must be configured to monitor one or more SVPs. The SVM will only collect and display information from SVPs that it is configured to monitor. Each SVM can monitor up to 10 SVPs. Commands The table below lists the commands necessary to configure the SVM to monitor one or more SVPs. Command rcpm monitor Configuration Example The following example configures the SVM to monitor an SVP with the IP address 192.168.1.3. configure terminal rcpm monitor rcp-ip-address 192.168.1.3 end copy running-config startup-config Description Provision SVP that this SVM is supposed to monitor.
5.2
5-1
SVM Configuration
The http service is enabled so users can connect to the SVM Dashboard
copy ftp://username:password@192.168.1.5/netsocket.crt ftproot: copy ftp://username:password@192.168.1.5/netsocket.key ftproot: ! ssl-certificate-install ! configure terminal enable service http end copy running-config startup-config
5.3
5-2
SVM Configuration
5.4
Configuration Example The example below configures the SVM to send email notification of alerts. The example uses domain name of enterprise.com. The alert emails will be sent with a From ID of NYSVM@enterprise.com. The SVM is configured to send alert emails to two email accounts, user1@enterprise.com and user2@enterprise.com. The send-alert command that follows saving the running configuration will send a test e-mail to both users with the subject line Initial Install Test Email. configure terminal ! hostname NYSVM ! ip domain-name enterprise.com ip name-server 10.25.15.9 ! send-alert user-email user1@enterprise.com send-alert user-email user2@enterprise.com ! enable service e-mail domain-name enterprise.com ! end copy running-config startup-config ! send-alert mail-test subject "Initial Install Test Email"
5-3
SVM Configuration
5.5
Software Upgrade
A software upgrade consists of the following three steps: 1. Copy the software load to the swdepot directory on the SVM 2. Upgrade the SVPs and SVAs via the SVM Dashboard 3. Upgrade the SVM via the SVM CLI Software upgrade of the SVPs and SVAs (step 2 in the list above) is done using the SVM Dashboard which is executed from a browser. The procedure is explained in the SVSS User Guide. Steps 1 and 3 are performed using the SVM CLI and are explained in the sections below. The SVM upgrade is done from the SVM CLI since the Web Server is halted as part of the upgrade process making it impossible to monitor the progress of the upgrade from the browser. Commands The table below lists the commands used in the Software Upgrade Command copy dir install Copy Command Example The following example assumes the NetSocket software is available via ftp on 192.168.1.5.
copy ftp://user:pass@192.168.1.5/netsocksw-1.9.0.0.0.0-2012Feb21.tgz swdepot: Connected to 192.168.1.5. 220 swdepot.netsocket.com FTP server (Version 6.00LS) ready. 331 Guest login ok, send your email address as password. 230 Guest login ok, access restrictions apply. 200 Type set to I. 250 CWD command successful. Local directory now / local: netsocksw-1.9.0.0.0.0-2012Feb21.tgz remote: netsocksw-1.9.0.0.0.02012Feb21.tgz 200 PORT command successful. 150 Opening BINARY mode data connection for netsocksw-1.9.0.0.0.02012Feb21.tgz 100% |******************************************************| 391 MB 00:00 ETA 226 Transfer complete. 410715530 bytes received in 44.42 seconds (8.82 MB/s) 221 Goodbye.
Description Copy the software package to the swdepot directory in preparation for the upgrade Lists files in a directory Install the software on the system
5-4
SVM Configuration
The contents of the swdepot directory can be displayed using the dir command as shown below.
dir swdepot: Directory of swdepot:/ -rw-rw445997385 469230902 Oct 20 20:54:12 2011 Feb 21 16:49:06 2012 netsocksw-1.8.0.5.0.0-2011Oct20.tgz netsocksw-1.9.0.0.0.0-2012Feb21.tgz
Install Command Example Note: After entering the install command the system will prompt for confirmation. To continue the installation type a y as shown below.
install netsocksw-1.9.0.0.0.0-2012Feb21.tgz self !!!This is an active stand-alone mcp. Enter 'Y/y' to proceed[confirm?(y|n)]y Installing package [netsocksw-1.9.0.0.0.0-2012Feb21.tgz] Validating package [etsocksw-1.9.0.0.0.0-2012Feb21] needs 413601274 bytes in /swdepot partition Unpacking sub-package Validating package [routerChiaros-1.9.0.0.0.452-2012Feb21] needs 8929 bytes in / partition needs 43543689 bytes in /swdepot partition Unpacking sub-package ...
5-5