Cisco_Systems_Telephone

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL

STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT

WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT

SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE

OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB???s public domain version of the UNIX operating system. All rights reserved. Copyright ?? 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED ???AS IS??? WITH

ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT

LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF

DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING,

WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO

OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)

Cisco BTS 10200 Softswitch Operations and Maintenance Guide

Preface

Revised: February 18, 2010, OL-16000-07

Introduction

This document is the Operations and Maintenance Guide for the Cisco BTS 10200 Softswitch, Release 6.0.1.

Organization

This guide has the following chapters:

???Chapter 1, ???Starting and Shutting Down the BTS??????Tells you how to start up and shut down the BTS

???Chapter 2, ???Managing BTS Users and Commands Using EMS??????Describes operator interfaces to the BTS and how to manage access and users

???Chapter 3, ???Monitoring and Backing Up the BTS??????Includes overall BTS maintenance strategies

???Chapter 4, ???Operating the BTS??????Tells you how to operate the BTS

???Chapter 5, ???Managing External Resources??????Tells you how to manage external resources provisioned on the BTS using administrative (ADM) commands

???Chapter 6, ???Using BTS Measurements??????Describes BTS traffic measurements and tells you how to use them

???Chapter 7, ???Using the BTS SNMP Agent??????Explains how to use the Simple Network Management Protocol (SNMP) agent

???Appendix A, ???Feature Tones??????Explains special tones the BTS supports for subscriber and operator features

???Appendix B, ???FIM/XML??????Explains the Feature Interaction Module/Extensible Markup Language (FIM/XML) feature.

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Preface

Introduction

Document Change History

This table provides the revision history for the Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x.

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What???s New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

C H A P T E R 1

Starting and Shutting Down the BTS

Revised: February 18, 2010, OL-16000-07

Introduction

This chapter tells you how to start up and shut down the BTS.

Meeting Power Requirements

To meet high availability requirements:

???Do not have common parts in the power feeds to the redundant hardware that could be a common single point of failure.

???Use uninterruptible power supply (UPS) for both AC and DC systems. It must be designed to support system operation through any possible power interruption. Power must have battery backup to maintain service in the event of commercial power failure (both power supplies of the redundant pair must be able to do this).

???For AC-powered installations have two separate (redundant) circuits. Source AC circuits from separate transformer phases on separate breakers so a single breaker trip does not disable both.

???For DC-powered installations have power from two separate dedicated DC branches (redundant A and B feeds) for each DC-powered BTS.

Starting BTS Hardware

The time it takes to complete this procedure varies with system type and database size. System types include:

???EMS???Element Management System

???BDMS???Bulk Data Management System

???CA???Call Agent

???FS???Feature Server

Step 1 Ensure all power cables connect to the correct ports.

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 1 Starting and Shutting Down the BTS

Shutting Down BTS Hardware

Step 2 Plug in Catalyst switch routers.

Step 3 Power on EMS/BDMS hosts A and B.

Step 4 Power on CA/FS hosts A and B.

Shutting Down BTS Hardware

Step 1 Ensure CA side A and EMS side A are active.

Step 2 Ensure CA side B and EMS side B EMS are standby.

Step 3 Log into CA side A and B and EMS side A and B using Secure Shell (SSH).

Step 4 Shut down the system in order:

1.EMS side B

2.CA side B

3.CA side A

4.EMS side A

Step 5 To begin platform shutdown:

>platform stop all

Step 6 When #> returns, enter nodestat to ensure the operating system is ready for shutdown.

Step 7 To shut down the servers, enter one of the following commands for each node (Sun Microsystems recommends both as graceful shutdowns).

>shutdown -i5 -g0 -y

Or:

>sync;sync; init5

Step 8 To power off primary and secondary CAs and FSs find the switch to the left of the LEDs and flip it to OFF.

Step 9 When the fans stop, release the switch to neutral.

Step 10 To power off primary and secondary EMSs find the switch to the left of the LEDs and flip it to OFF.

Step 11 When the fans stop, release the switch to neutral.

Step 12 To power off the side, unplug them.

Starting BTS Software

BTS automatically starts when you power on the server. Repeat this procedure for each server.

Step 1 Enter nodestat.

Step 2 Log in as root.

Step 3 Enter platform start.

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

C H A P T E R 2

Managing BTS Users and Commands Using EMS

Revised: February 18, 2010, OL-16000-07

Introduction

This chapter describes operator interfaces to the BTS and how to manage access and users.

The Element Management System (EMS) database holds up to 256 logins and up to 50 active user sessions.Using the command line interface (CLI) you can locally connect to the EMS in an interactive session.The EMS system administrator can:

???Add a new user.

???Assign a user???s privilege level???10 is for the system administrator. BTS has predefined user accounts:

???Reset a user???s password.

???Enter a description for each security class and privilege level.

???Manage security log reporting.

Logging into the EMS Using CLI

SSH is a way to access the BTS CLI or maintenance (MAINT) modes. SSH provides encrypted communication between a remote machine and the EMS/CA for executing CLI or MAINT commands. The SSH server runs on EMSs and CAs. To connect the client and server sides run the secure shell daemon (SSHD). With SSH, new users must enter a new password and reenter that password during the first login. In future logins they are prompted once for a password only.

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 2 Managing BTS Users and Commands Using EMS

Managing Users

The ???ciscouser??? login is a high-level security login for TAC and other BTS support personnel that restricts access to certain commands. Anyone else trying to execute such commands receives an error message.

After installation, on the EMS, the system prompts you to change the passwords of root, btsadmin, btsuser and calea if they have default passwords. On the CA, the system prompts you to change the passwords of root if it has default password. There are no default passwords for Operations, Administration and Maintenance applications.

When logging in for the first time system administrators log in as btsadmin (the default password is btsadmin). Change the password.

Step 1 To log in from the client side for the first time: ssh btsadmin@<ipaddress>.

Note If you are logged in to the system as root, enter: btsadmin@0

On the first SSH login from the client side, expect a message like this:

The authenticity of host [hostname] can't be established.

Key fingerprint is 1024 5f:a0:0b:65:d3:82:df:ab:42:62:6d:98:9c:fe:e9:52.

Are you sure you want to continue connecting (yes/no)?

Step 2 Enter yes.

The password prompt appears, now all communications are encrypted.

Step 3 Enter your password.

The system responds with a CLI> prompt. You can now send commands to the EMS.

Step 4 Enter provisioning commands.

Step 5 To log off, enter exit .

Managing Users

You must have a user privilege level of 9 or higher to add, show, change, or delete a user.

Caution Do not add, change, or delete username root, this prevents proper EMS access.

Table 2-1 Managing Users

Chapter 2 Managing BTS Users and Commands Using EMS

Managing Users

Table 2-1 Managing Users (continued)

Note You cannot block the session of a user with higher privileges than yours.

Prevent BTS provisioning during an upgrade or maintenance window from the following interfaces:

???CLI

???FTP

???CORBA

???SNMP

Note The software will support blocking HTTP interfaces in a future release.

Chapter 2 Managing BTS Users and Commands Using EMS

Managing Commands

Note All commands should be assigned to a work-group. If a command is not assigned to a work-group, a user will able to execute that command, which is not recommended. You can also assign users and the commands to multiple work-groups.

Managing Commands

Each command (verb-noun combination) has a security class of 1-10; 1 is lowest, 10 is highest. Each time a user enters a command, the system compares the user???s privilege level to the command???s security class. EMS denies the command if the user level is less than the command level.

The Command Level (command-level) table shows the 10 command security classes. BTS has the following presets:

???1 (lowest level)

???5 (mid-level)

???10 (highest level)???These commands require a system administrator with a security level of 10 to execute.

Table 2-2 Managing Commands

This chapter details the behaviors and attributes of the various security packages in the BTS 10200. The sources for the items are derived from many dynamic sources. Included in these sources are security bulletins from third-party vendors to the BTS 10200 as well as security agencies and open source organizations.

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 2 Managing BTS Users and Commands Using EMS

Adapter and User Security

Security is an important part of the BTS 10200. The BTS 10200 has interfaces to customer premise equipment (CPE) as well as northbound Operations Support System (OSS) interfaces. All of these interfaces are subject to attacks. In addition, users who are allowed onto the BTS 10200 can also find ways to exploit applications that can lead to service-affecting situations. Therefore, many precautions are taken to ensure the solidity of the BTS 10200 defenses while avoiding a system that is difficult to manage.

Figure 2-1 BTS 10200 Access and Related Security

Adapter and User Security

104705

This section describes requirements that generally involve adapter and user level of security. In the BTS 10200, adapters are any external, northbound interfaces of the BTS 10200. However, some extrapolated requirements involve adapter technology based on the current deployment:

???Support termination of a session once a provisionable inactivity timeout has occurred. An event report is issued upon each timeout expiry. The inactivity time ranges from 10 to 30 minutes.

???Restrict access as ???root??? to the BTS 10200 in all cases except Cisco TAC and customer ???administrator???. This is a broad statement that includes the addition of command-line interface (CLI) commands to help manage the system. In addition, UNIX services are restricted to harden the operating system (OS). The service restriction is listed in the Solaris OS Security and BTShard Package section. The process of restricting root access is an ongoing process.

???Use of ???sudo" is acceptable and the formal Sun-built and packaged version is located in /opt/sfw/bin/.

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 2 Managing BTS Users and Commands Using EMS

Solaris OS Security and BTShard Package

This section details the security packages for the BTS 10200 OS. These packages are automatically installed at installation. These packages are derived from both Sun Microsystems security bulletins and Cisco internal policies for safety of the OS and its applications. All services can be reactivated for the lifetime of the current kernel instance. All settings are reset on reboot of the kernel. These settings are contained in the BTShard Solaris package delivered with the BTS 10200.

???Remove unnecessary UNIX systems services. These services are listed below. Management of these facilities must allow for each service to be enabled or disabled on an individual basis. This service management must also be accomplished through the BTS 10200 adapter interface.

???FTP???FTP server is disabled and SFTP (Secure FTP) should be used. This impacts the Bulk Data Provisioning interface. It does not impact the Billing Bulk Data transfer. The FTP client code will still be available on the EMS node.

???Telnet???This terminal protocol is disabled and SSH (Secure Shell) should be used. The telnet server and client code are still available on the EMS node.

???Echo???This service is to be disabled. This capability has been replaced with Internet Control Message Protocol (ICMP) ???ping??? facilities.

???Discard???This service is to be disabled.

???Printer???This service is to be disabled. No printer services are supplied in the BTS 10200 product description.

???Daytime???This service is to be disabled.

???Chargen???This service is to be disabled.

???SMTP???This service is to be disabled.

???Time???This service is to be disabled.

???Finger???This service is to be disabled. No network user facilities are required. The BTS 10200 tracks users internally and on a single BTS basis.

???Sun RPC???This service is to be disabled. This may be enabled in a lab environment for Tooltalk usage in debugging application programs.

???Exec???This service is to be disabled.

???Login???This service is to be disabled.

???Shell???This service is to be disabled. This may be required for some lab activity; however, there is no field usage for rlogin, rcp, and rsh facilities.

???UUCP???This service is to be disabled.

???NFS???This service is to be disabled.

???Lockd???This service is to be disabled.

???X11???This service is available for the near term only.

???DTSCP???This service is to be disabled.

???Font-services???This service is to be disabled.

???HTTP???This service is to be enabled. This is used by the BTS 10200 to offer results of report generation. This will migrate to HTTPS.

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 2 Managing BTS Users and Commands Using EMS

Solaris OS Security and BTShard Package

???The following UNIX accounts are to be LOCKED but not removed from the system: lp, uucp, nuucp, nobody, listen, and any other Cisco support accounts not used in the normal course of field operation. Services managed by root are the only accounts allowed to utilize one of these identities. This is the default behavior.

???Modifications to the Solaris kernel parameters were made to close potential breeches in the OS. These types of security precautions are most often geared toward ???denial of service??? attacks. These types of attacks create situations that degrade the performance of a system and as a result, prohibit the critical applications from delivering the service they are designed to provide.

???The TCP protocol uses random initial sequence numbers.

???All failed login attempts are logged.

???The following users are not allowed direct FTP access to the machine: root, daemon, bin, sys, adm, nobody, and noaccess.

???A root user cannot telnet directly to the machine. Direct root user access is granted to the console only. A user who wants to access the root account must use the su command from a nonprivileged account.

???The break key (<STOP> <A>) on the keyboard is disabled.

???IP_FORWARD_DIRECTED_BROADCASTS???This option determines whether to forward broadcast packets directed to a specific net or subnet, if that net or subnet is directly connected to the machine. If the system is acting as a router, this option can be exploited to generate a great deal of broadcast network traffic. Turning this option off helps prevent broadcast traffic attacks. The Solaris default value is 1 (True). For example:

ip_forward_directed_broadcasts=0

???IP_FORWARD_SRC_ROUTED???This option determines whether to forward packets that are source routed. These packets define the path the packet should take instead of allowing network routers to define the path. The Solaris default value is 1 (True). For example:

ip_forward_src_routed=0

???IP_IGNORE_REDIRECT???This option determines whether to ignore the ICMP packets that define new routes. If the system is acting as a router, an attacker may send redirect messages to alter routing tables as part of sophisticated attack (man-in-the-middle attack) or a simple denial of service. The Solaris default value is 0 (False). For example:

ip_ignore_redirect=1

???IP_IRE_FLUSH_INTERVAL???This option determines the period of time at which a specific route will be kept, even if currently in use. Address Resolution Protocol (ARP) attacks may be effective with the default interval. Shortening the time interval may reduce the effectiveness of attacks. The default interval is 1200000 milliseconds (20 minutes). For example:

ip_ire_flush_interval=60000

???IP_RESPOND_TO_ADDRESS_MASK_BROADCAST???This option determines whether to respond to ICMP netmask requests, typically sent by diskless clients when booting. An attacker may use the netmask information for determining network topology or the broadcast address for the subnet. The default value is 0 (False). For example:

ip_respond_to_address_mask_broadcast=0

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 2 Managing BTS Users and Commands Using EMS

Solaris OS Security and BTShard Package

???IP_RESPOND_TO_ECHO_BROADCAST???This option determines whether to respond to ICMP broadcast echo requests (ping). An attacker may try to create a denial of service attack on subnets by sending many broadcast echo requests to which all systems will respond. This also provides information on systems that are available on the network. The Solaris default value is 1 (True). For example:

ip_respond_to_echo_broadcast=1

???IP_RESPOND_TO_TIMESTAMP???This option determines whether to respond to ICMP timestamp requests, that some systems use to discover the time on a remote system. An attacker may use the time information to schedule an attack at a period of time when the system may run a cron job (or other time-based event) or otherwise be busy. It may also be possible predict ID or sequence numbers that are based on the time of day for spoofing services. The Solaris default value is 1 (True). For example:

ip_respond_to_timestamp=0

???IP_RESPOND_TO_TIMESTAMP_BROADCAST???This option determines whether to respond to ICMP broadcast timestamp requests, that are used to discover the time on all systems in the broadcast range. This option is dangerous for the same reasons as responding to a single timestamp request. Additionally, an attacker may try to create a denial of service attack by generating many broadcast timestamp requests. The default value is 1 (True). For example:

ip_respond_to_timestamp_broadcast=0

???IP_SEND_REDIRECTS???This option determines whether to send ICMP redirect messages, that can introduce changes into the routing table of the remote system. It should only be used on systems that act as routers. The Solaris default value is 1 (True). For example:

ip_send_redirects=0

???IP_STRICT_DST_MULTIHOMING???This option determines whether to enable strict destination multihoming. If this is set to 1 and ip_forwarding is set to 0, then a packet sent to an interface from which it did not arrive will be dropped. This setting prevents an attacker from passing packets across a machine with multiple interfaces that is not acting a router. The default value is 0 (False). For example:

ip_strict_dst_multihoming=1

???TCP_CONN_REQ_MAX_Q0???This option determines the size of the queue containing half-open connections. This setting provides protection from SYN flood attacks. Solaris 2.6 and 7 (and 2.5.1 with patch 103582-12 and higher) include protection from these attacks. The queue size default is adequate for most systems but should be increased for busy web servers. The default value is 1024. For example:

tcp_conn_req_max_q0=4096

???The following startup files are removed from the level ???3??? runtime environment of the BTS 10200. These services can still be started manually if required in laboratory circumstances. They are not required for field operations.

???S71rpc

???S73cachefs.daemon

???S73nfs.client

???S74autofs

???S80lp

???S80spc

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 2 Managing BTS Users and Commands Using EMS

Solaris OS Security and BTShard Package

???S88sendmail

???S93cacheos.finish

???S99dtlogin

Operator Interface

Additional commands have been added to manage the UNIX services in the BTS 10200. These commands are available from the CLI/MAINT interface. In addition, these same commands are also available from the CORBA and bulk-provisioning interface. There are no schemas and tables associated with these commands. They directly control the UNIX services. These services are only enabled for the lifetime of the current kernel instance. They are reset to the installed defaults when a kernel reboot is performed.

Table 2-3 describes the system services available using the node command.

Chapter 2 Managing BTS Users and Commands Using EMS

Solaris OS Security and BTShard Package

Vulnerabilities in H.323 Message Processing

During 2002 the University of Oulu Security Programming Group (OUSPG) discovered a number of implementation-specific vulnerabilities in the Simple Network Management Protocol (SNMP). Subsequent to this discovery, the National Infrastructure Security Coordination Centre (NISCC) performed and commissioned further work on identifying implementation specific vulnerabilities in related protocols that are critical to the United Kingdom Critical National Infrastructure. One of these protocols is H.225, that is part of the H.323 family and is commonly implemented as a component of multimedia applications such as Voice over IP (VoIP).

OUSPG produced a test suite for H.225 and employed it to validate their findings against a number of products from different vendors. The test results have been confirmed by testing performed by NISCC and the affected vendors contacted with the test results. These vendors' product lines cover a great deal of the existing critical information infrastructure worldwide and have therefore been addressed as a priority. However, the NISCC has subsequently contacted other vendors whose products employ H.323 and provided them with tools with which to test these implementations.

Authentication, Authorization and Accounting Support

These extensions represent modifications to the current scheme of user account management on the system. It includes support for the following two protocols; these protocols are not required to be mutually inclusive.

???Radius Protocol

???Lightweight Directory Access Protocol (LDAP)

Prior to Release 4.4, user account management for the BTS 10200 used the standard Solaris password management facilities without the use of the Authentication Dial-In User Service Network Information Service (NIS). All accounts are stored locally and referenced locally. This security feature begins support for a complete AAA model for user account management. This model impacts several internal subsystems of the BTS 10200 Element Management System (EMS) application. It also impacts the core login support on the other nodes of the BTS 10200.

Chapter 2 Managing BTS Users and Commands Using EMS

Sun Microsystems Configurations

Pluggable Authentication Module Support

The BTS 10200 deploys a Secure Shell (SSH) package with Pluggable Authentication Module (PAM) support. The package includes the PAM support required to utilize the Radius and LDAP servers.

The supporting configuration allows local accounts to fall through if the Radius and LDAP servers are not available. These default local accounts for the BTS 10200 are the btsuser, btsadmin and secadmin accounts. These are the standard default accounts provided in the base product and use the native password management.

A UNIX-based user provides access to the operating system on all nodes. The oamp user is defined for package management purposes. The account is locked and no password is available. However, to grant UNIX access to all nodes of the BTS 10200, a default password is provided.

When PAM support is used, SSH transfers the control of authentication to the PAM library, that then loads the modules specified in the PAM configuration file. Finally, the PAM library tells SSH whether the authentication was successful. SSH is not aware of the details of the actual authentication method employed by PAM. Only the final result is of interest.

User Security Account Management

The BTS 10200 EMS contains an application program known as User Security Management (USM). This program determines if an account is local or off-board. Password management facilities are disabled for all accounts on the BTS 10200 when an AAA deployment is configured. The AAA deployment transfers the responsibility for these existing facilities to the end-user AAA servers. These facilities include the following attributes:

???Password aging, warning, and expiration

???Password reset and automatic account locking

???Local account management (password and shadow files) for new accounts

Sun Microsystems Configurations

Table 2-4 lists the Solaris 10 architecture-specific or hardware specific packages for certain Sun Microsystems configurations.

Chapter 2 Managing BTS Users and Commands Using EMS

Solaris OS Patches

This chapter describes the BTS 10200 Solaris OS patches.

Trace Normal Forms (TNF) Support

The TNF package provides the Solaris tool suite with enhanced debugging capabilities of applications as they execute in the target environment. TNF supports program execution traces at both the user and kernel level The package includes the following:

???SUNWtnfc???Utilities needed to enable probe points, in the kernel and in applications, that can generate TNF records in a trace file.

Chapter 2 Managing BTS Users and Commands Using EMS

Solaris OS Patches

???SUNWtnfd???Utilities needed by developers using TNF facilities.

???SUNWtnfx???The 64-bit utilities needed to enable probe points, in the kernel and in applications, that can generate TNF records in a trace file.

XML Libraries

The Sun VTS software requires the use of the XML libraries on the BTS 10200. These are in the supplemental part of the Solaris distribution with the VTS packages. These XML libraries and tools for 32 and 64 bit usage are listed as follows:

???SUNWxmlS

???SUNWlxml

???SUNWlxmlx

Device GLM Patch

The 109885-16 patch corrects several open bug reports on the SCSI device driver GLM in the Solaris OS.

Security CE Patch

The 111883-24 patch corrects Sun GigaSwift Ethernet 1.0 driver.

Security Bad_Trap Patch

The 117000-05 patch is a new generic kernel patch that cumulates many kernel level bug fixes into a single patch. This supersedes the older generic patch 108528-29.

Java SDK Patches

The upgraded version of Java requires some additional patches to the kernel and system libraries to support the required functionality. The patches are listed below. These are the relevant patches from the recommended cluster of patches as produced by Sun Microsystems.

???109147-30???The SunOS 5.8: linker patch.

???111308-05???The SunOS 5.8: /usr/lib/libmtmalloc.so.1 patch.

???112438-03???The SunOS 5.8: /kernel/drv/random patch.

???108434-17???The SunOS 5.8: 32-Bit Shared library patch for C++.

Note 108435-17 is the corresponding 64-bit patch.

???108435-17???The SunOS 5.8: 64-Bit Shared library patch for C++ Note: 108434-17 is the corresponding 32-bit patch.

???111111-04???The SunOS 5.8: /usr/bin/nawk patch.

C H A P T E R 3

Monitoring and Backing Up the BTS

Revised: February 18, 2010, OL-16000-07

Introduction

This chapter includes overall BTS maintenance strategies.

Detecting and Preventing BTS Congestion

When congested the BTS automatically does the following:

???Detects internal messaging congestion caused by traffic overload or other extraordinary events.

???Takes preventive action to avoid system failure (including shedding of traffic).

???Generates alarms when it detects internal messaging.

???Clears the alarms when congestion abates.

???Places the access control list (ACL) parameter (indicating congestion) into release messages sent to the SS7 network when the BTS internal call processing engine is congested.

???Routes emergency messages. Exact digit strings for emergency calls differ, specify up to ten digit strings (911 and 9911 are included by default). Contact Cisco TAC to do this, it involves a CA restart.

???Generates a SS7 termination cause code 42 for billing.

???Generates the cable signaling stop event with cause code ???resource unavailable??? for billing.

See the Cisco BTS 10200 Softswitch Troubleshooting Guide, Release 6.0.1 for congestion alarms.

Monitoring BTS Hardware

BTS tracks devices and facilities that exceed their settings.

???A process exceeds 70 percent of the CPU.

???The Call Agent CPU is over 90 percent busy (10 percent idle).

???The load average exceeds 5 for at least a 5-minute interval.

???Memory is 95 percent exhausted and swap is over 50 percent consumed.

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 3 Monitoring and Backing Up the BTS

Checking BTS System Health

???Partitions consumed:

???A partition 70 percent consumed generates a minor alarm.

???A partition 80 percent consumed generates a major alarm.

???A partition 90 percent consumed generates a critical alarm.

Table 3-1 Managing Hardware

Checking BTS System Health

Do the following tasks as listed or more frequently if your system administrator recommends it.

Chapter 3 Monitoring and Backing Up the BTS

Checking BTS System Health

Table 3-3 Using BTS System-Health Reports (continued)

Checking BTS System Time

BTS clocks must be accurate to 2 seconds.

Caution Do not change the date or time in your BTS host machines while CA, FS, EMS, and BDMS are running. Instead allow the Solaris OS to get the time automatically through NTP services.

Step 1 Log in to the primary and secondary EMSs as root.

Step 2 Enter <hostname># date.

Step 3 On each EMS ensure the following are correct:

a.The time does not deviate more than +/- 2 seconds.

b.Day, month, year, time zone

Step 4 Log in to both the primary and secondary CA as root.

Step 5 Enter <hostname># date.

Step 6 On each CA ensure the following are correct:

a.The time is accurate to within +/-2 seconds of the correct time.

b.Day, month, year, time zone

Checking the OS Log of Each Host Machine

Monitor the OS logs on all four host machines (primary and secondary EMS, primary and secondary CA) for errors or warnings. This report shows you recent messages like memory hits, disk errors, and frequent process restarts.

Step 1 Log in as root.

Step 2 Enter dmesg.

Step 3 For more history edit the /var/adm/messages file.

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 3 Monitoring and Backing Up the BTS

Checking BTS System Health

Checking Disk Mirroring on Each Host Machine

Each procedure takes about 30 minutes.

CA/FS Side A

Before doing this procedure, ensure your BTS platform is connected to controller 1 or controller 0.

Step 1 Log in as root to CA/FS side A using telnet.

Step 2 Enter one of the following:

<hostname># metastat | grep c0

Or:

<hostname># metastat | grep c1

Step 3 Verify the return matches the following:

If the results differ synchronize the disk mirroring:

<hostname># cd /opt/setup

<hostname># sync_mirror

Verify the results using Step 1 through Step 3.

Caution In case of a mismatch, synchronize once. If the mismatch continues, contact Cisco TAC.

CA/FS Side B

Step 1 Log in as root to CA/FS side B using telnet.

Step 2 Enter <hostname># metastat | grep c0.

Step 3 Verify the return matches the following:

c0t0d0s6 0 No Okay c0t1d0s6 0 No Okay c0t0d0s1 0 No Okay c0t1d0s1 0 No Okay c0t0d0s5 0 No Okay c0t1d0s5 0 No Okay

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 3 Monitoring and Backing Up the BTS

Checking BTS System Health

c0t0d0s7 0 No Okay c0t1d0s7 0 No Okay c0t0d0s0 0 No Okay c0t1d0s0 0 No Okay c0t0d0s3 0 No Okay c0t1d0s3 0 No Okay

If the results differ synchronize the disk mirroring:

<hostname># cd /opt/setup

<hostname># sync_mirror

Verify the results using Step 1 through Step 3.

Caution In case of a mismatch, synchronize once. If the mismatch continues contact Cisco TAC.

EMS Side A

Step 1 Log in as root to EMS side A using telnet.

Step 2 Enter <hostname># metastat | grep c0.

Step 3 Verify the return matches the following:

c0t0d0s6 0 No Okay c0t1d0s6 0 No Okay c0t0d0s1 0 No Okay c0t1d0s1 0 No Okay c0t0d0s5 0 No Okay c0t1d0s5 0 No Okay c0t0d0s7 0 No Okay c0t1d0s7 0 No Okay c0t0d0s0 0 No Okay c0t1d0s0 0 No Okay c0t0d0s3 0 No Okay c0t1d0s3 0 No Okay

If the results differ synchronize the disk mirroring:

<hostname># cd /opt/setup

<hostname># sync_mirror

Verify the results using Step 1 through Step 3.

Caution In case of a mismatch, synchronize once. If the mismatch continues contact Cisco TAC.

EMS Side B

Step 1 Log in as root to EMS side B using telnet.

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 3 Monitoring and Backing Up the BTS

Checking BTS System Health

Step 2 Enter <hostname># metastat | grep c0.

Step 3 Verify the return result matches the following:

If the results differ synchronize the disk mirroring:

<hostname># cd /opt/setup <hostname># sync_mirror

Verify the results using Step 1 through Step 3.

Caution In case of a mismatch, synchronize once. If the mismatch continues contact Cisco TAC.

Auditing Databases and Tables

Audit either the complete database or entries in every provisionable table in both the Oracle database and shared memory. See the Cisco BTS 10200 Softswitch Troubleshooting Guide, Release 6.0.1.

Caution Audits are time-intensive. Do only during a maintenance window. Completion time varies with database or table entries.

Table 3-4 Auditing Databases and Tables

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 3 Monitoring and Backing Up the BTS

Exporting Provisioned Data

Table 3-4 Auditing Databases and Tables (continued)

Exporting Provisioned Data

The CLI Native Data Export feature enables the export of all provisioning data from the BTS 10200 system by the use of a CLI command. Execution of the CLI command stores the exported data in a user-named output file in text format in the export directory. The exported file contains all provisioning data from the BTS 10200. The provisioning data is written into the export file using add and change commands for all supported nouns.

The key attributes of the CLI Native Data Export feature are

???The user can run the CLI command to export the BTS 10200 provisioning data.

???The provisioning data for all the nouns, which enables the use of verbs as ???add??? and ???change??? is exported in text format.

???The list of all the nouns related to provisioning is kept in an input file (xml format). Upon execution of the export command, the xml input file reads the nouns and their corresponding verbs (operation type, whether add or change), and exports the provisioning data from the BTS 10200.

The CLI export command is:

CLI > export database outfile = <whatever>

Where the noun is database and the verb is export. Execution of the command exports all of the provisioning data from the BTS 10200. All of the exported data is written in the output file as specified by the user. The output file contains all the add and change commands for the existing native data in the BTS 10200. The exported output file is stored in the /opt/ems/export directory.

The result of the export command is a text file that contains add/change CLI commands. The following is an example output text file:

#BTS Config Export

#EMS Server: priems26-ora

#User: optiuser

#Export Start Time : Tue Jan 22 17:23:54 CST 2008

#########################

##### Add clli_code #####

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 3 Monitoring and Backing Up the BTS

Exporting Provisioned Data

#########################

add clli_code ID=ABCD1234567;

##########################

##### Add call_agent #####

##########################

add call_agent id=CA146;tsap_addr=CA146.A.12345678901234567890123456789012345678 901234567890123456;mgw_monitoring_enabled=N;clli=ABCD1234567;

##############################

##### Add feature_server #####

##############################

add feature_server ID=FSAIN205;TSAP_ADDR=FSAIN.A.1234567890123456789012345678901 2345678901234567890123456;TYPE=AIN;DESCRIPTION=123456789012345678901234567890123 456789012345678901234567890ABCD;EXTERNAL_FEATURE_SERVER=N;

add feature_server ID=FSPTC235;TSAP_ADDR=FSPTC.A.1234567890123456789012345678901 2345678901234567890123456;TYPE=POTS;DESCRIPTION=12345678901234567890123456789012 3456789012345678901234567890ABCD;EXTERNAL_FEATURE_SERVER=N;

####################################

##### Change billing_acct_addr #####

####################################

################################

##### Change billing_alarm #####

################################

####################################

##### Change report_properties #####

####################################

change report_properties TYPE=EVENT_LOGSIZE;VALUE=30000; change report_properties TYPE=ALARM_LOGSIZE;VALUE=30000; change report_properties TYPE=EVENT_LEVEL;VALUE=INFO;

#############################

##### Change sup_config #####

#############################

change sup_config TYPE=refresh_rate;VALUE=86400; change sup_config TYPE=priority;VALUE=5;

change sup_config TYPE=subterm_mgw_block;VALUE=5; change sup_config TYPE=subterm_block_pause;VALUE=9000; change sup_config TYPE=subterm_status_pause;VALUE=0; change sup_config TYPE=trunkterm_tg_block;VALUE=5; change sup_config TYPE=trunkterm_block_pause;VALUE=9000; change sup_config TYPE=trunkterm_status_pause;VALUE=0; change sup_config TYPE=trunkterm_range_block;VALUE=1000;

change sup_config TYPE=trunkterm_range_pause;VALUE=20000;

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 3 Monitoring and Backing Up the BTS

Exporting Provisioned Data

#############################################

##### Change command_throttle_threshold #####

#############################################

change command_throttle_threshold SESSION_TYPE=CLI;THRESHOLD=100;ENABLE=Y; change command_throttle_threshold SESSION_TYPE=CORBA;THRESHOLD=100;ENABLE=Y; change command_throttle_threshold SESSION_TYPE=FTP;THRESHOLD=1000;ENABLE=Y; change command_throttle_threshold SESSION_TYPE=MNT;THRESHOLD=100;ENABLE=Y; change command_throttle_threshold SESSION_TYPE=SNMP;THRESHOLD=100;ENABLE=Y; change command_throttle_threshold SESSION_TYPE=SOAP;THRESHOLD=100;ENABLE=Y;

##################################

##### Change config_interval #####

##################################

change config_interval CONFIG_TYPE=THROTTLE;INTERVAL=15;

# Export End Time : Tue Jan 22 17:24:14 CST 2008

Limitations

Currently the export command is supported only from the CLI interface. The export command is currently not supported from other interfaces such as CORBA and SOAP.

There is a limitation on the size of the /opt/ems/export directory. Currently the size of the export directory is defined in /opt/ems/etc/bts.properties as 7500000 ~ 700 MB. During the first run of the export command, if the size of the export file is beyond the threshold limit, a warning message is shown to the user after export is finished. The warning message indicates that the export file size has exceeded the threshold and that the user needs to clean up the export directory before running the command again. During additional runs of the export command, if the export directory size is more then the threshold size, a warning is shown to the user that the space of export directory is insufficient for the export and that the user has to clear the export directory before rerunning the export command.

Creating Numbering Resource Utilization/Forecast (NRUF) Reports

The North American Numbering Plan Association (NANPA) collects, stores, and maintains how telephone numbers are used by 19 countries. Companies, like carriers, that hold telephone numbers must report to NANPA twice a year using the NRUF report. Go to http://www.nanpa.com for more information and job aids on submitting reports.

The BTS creates an NRUF report using the Number Block table. This table:

???Is a single table that is the sole reference for NANPA audits

???Can be customized

???Can be updated from data imported from other tables, changes from office-code updates, or manually

???Has the following fields:

???Number Block: NPA to NPA-NXX-XXXX???For FCC-required NANPA audit compliance, the report input is NPANXX. In markets outside of NANPA, the input can be based on either the combination of the national destination code (NDC) and the exchange code (EC), or just the EC.

???Code Holder = Y/N

???Block Holder = Y/N

???Native = Y/N

Chapter 3 Monitoring and Backing Up the BTS

Exporting Provisioned Data

??? Non-Native = Y/N

To generate the following reports, use report dn-summary:

???All DNs in NDC and EC

???Thousands group in NDC and EC

???Operating company number (OCN)

???Switch Common Language Location Identifier (CLLI) code

???OCN + CLLI code???entries must match LERG data

Creating Reports for Nonrural Primary and Intermediate Carriers

NRUF reporting for nonrural primary and intermediate carriers:

???Occurs at a thousands-block level (NPA-NXX-X)

???Applies only to NANP

The report returns the following based on the DN2SUBSCRIBER table???s STATUS token:

Table 3-5 NRUF Report Data for Nonrural Carriers

Chapter 3 Monitoring and Backing Up the BTS

Exporting Provisioned Data

Table 3-5 NRUF Report Data for Nonrural Carriers (continued)

??? Administrative DID DNs:

??? Changed Number administrative DNs

Creating Reports for Rural Primary and Intermediate Carriers

This section identifies the DN information that is reported at the NPA-NXX level when the service provider is a code holder. NRUF reporting at the ???ndc, ec??? level includes dn-groups of varying length. Some countries might support dn-groups of length 1, 2, 3 or 4.

Chapter 3 Monitoring and Backing Up the BTS

Exporting Provisioned Data

???The Rural Primary Carrier (U2 form) NPA-NXX report has:

???NPA-NXX (input as ndc, ec)

???Rate Center (read from LERG)

???State (read from LERG)

???Number of Assigned DNs

???Number of Intermediate DNs

???Number of Reserved DNs

???Number of Aging DNs

???Number of Administrative DNs

???Donated to Pool (always 0)

???The Rural Intermediate Carrier (U4 form) report has:

???NPA-NXX (input as ndc, ec)

???Rate Center (read from LERG)

???State (read from LERG)

???Number of Assigned DNs

???Number of Intermediate DNs

???Number of Reserved DNs

???Number of Aging DNs

???Number of Administrative DNs

???Numbers Received (always 0)

The report returns the following based on the DN2SUBSCRIBER table???s STATUS token:

Chapter 3 Monitoring and Backing Up the BTS

Exporting Provisioned Data

Full Database Auditing

Step 1 Log in as CLI user on EMS side A.

Step 2 Enter audit database type=full;.

Step 3 Check the audit report and verify that there is no mismatch or error. If errors are found, try to correct the errors. If you cannot make the correction, contact Cisco TAC.

Checking Shared Memory

This task checks shared memory to detect potential data problems.

From CA/FS Side A

Chapter 3 Monitoring and Backing Up the BTS

Exporting Provisioned Data

The result should match the following:

All tables are OK.

For detail, see ain_tiat.out

Caution If the result is not???All tables are OK???, stop and contact Cisco TAC.

From CA/FS Side B

<hostname>#cd /opt/OptiCall/FSAINyyy/bin

<hostname>#ain_tiat data

Step 7 Press Enter:

The result should match the following:

All tables are OK.

For detail, see ain_tiat.out

Chapter 3 Monitoring and Backing Up the BTS

Exporting Provisioned Data

Caution If the result is not???All tables are OK???, stop and contact Cisco TAC.

Backing Up the Full BTS

Do this before and after software upgrades or as routine, always during a maintenance window. Before starting the provisioning process ensure you have the following:

Pre-Provisioning Checklist

NFS server hostname or ip address

Shared directory from NFS server

Root user access

Provisioning blocked

Backing Up the CA/FS

Perform the following steps to back up the secondary CA/FS. Then repeat the procedure on the primary CA/FS.

Step 1 Log in as root on the secondary CA/FS.

Step 2 Verify all platforms are in STANDBY mode, enter <hostname>#nodestat.

Step 3 Remove unnecessary files or directories like /opt/Build and application tar files.

Step 4 Mount the NFS server to the /mnt directory, enter <hostname>#mount <nfs server ip or hostname>:/<share dire> /mnt.

Step 5 Stop all platforms; enter <hostname>#platform stop all.

Step 6 Save all platforms data directory (shared memory) to nfs server

<hostname>#tar -cf - /opt/OptiCall/CAxxx/bin/data |gzip -fast - > /mnt/data.<hostname>.CA <<hostname>#tar -cf - /opt/OptiCall/CAxxx/bin/data |gzip --fast - > /mnt/data.<hostname>.CA.gz

<hostname>#tar -cf - /opt/OptiCall/FSAINxxx/bin/data |gzip --fast - > /mnt/data.<hostname>.FSAIN.gz

<hostname>#tar -cf /opt/OptiCall/FSPTCxxx/bin/data |gzip --fast - > /mnt/data.<hostname>.FSPTC.gz

where xxx is the instance number

Step 7 Start all platforms by entering <hostname>#platform start.

Step 8 Verify all platforms are in STANDBY mode, enter <hostname>#nodestat.

Step 9 Create an excluded directories file for the flash archive, enter:

<hostname>#vi /tmp/excluded_dir /opt/OptiCall/CAxxx/bin/data

/opt/OptiCall/CAxxx/bin/logs

Chapter 3 Monitoring and Backing Up the BTS

Exporting Provisioned Data

/opt/OptiCall/FSAINxxx/bin/data

/opt/OptiCall/FSAINxxx/bin/logs

/opt/OptiCall/FSPTCxxx/bin/data

/opt/OptiCall/FSPTCxxxx/bin/logs

where xxx is the instance number

Step 10 Back up the system, enter:

<hostname>#mv /bin/date /bin/date.archive <hostname>#mv /bin/.date /bin/date

<hostname>#flarcreate -n <hostname> -X /tmp/excluded_dir -c /mnt/<hostname>.archive <hostname>#mv /bin/date /bin/.date

<hostname>#mv /bin/date.archive /bin/date

Step 11 Unmount the NFS server, enter:

<hostname>#umount /mnt

Step 12 From the active EMS switch over all platforms, enter:

<hostname>#ssh optiuser@<hostname>

cli>control feature-server id=FSAINxxx;target-state=standby-active; cli>control feature-server id=FSPTCxxx;target-state=standby-active; cli>control call-agent id=CAxxx;target-state=standby-active;

where xxx is the instance number of each platform

Step 13 Repeat this procedure for the primary CA/FS.

Backing up the EMS/BDMS

Do the following to back up the STANDBY EMS/BDMS system.

Chapter 3 Monitoring and Backing Up the BTS

Exporting Provisioned Data

<hostname>#flarcreate -n <hostname> -X /tmp/excluded_dir -c /mnt/<hostname>.archive <hostname>#mv /bin/date /bin/.date

<hostname>#mv /bin/date.archive /bin/date

Step 11 Unmount the NFS server, enter <hostname>#umount /mnt.

Step 12 From the active EMS switch over all platforms, enter:

<hostname>#ssh optiuser@<hostname>

cli>control bdms id=BDMS01;target-state=standby-active; cli>control element-manager id=EM01;target-state=standby-active;

Step 13 Repeat the procedure starting with Step 3 to back up the PRIMARY EMS/BDMS.

Backing up the EMS Database

This procedure is for experienced UNIX users. It tells you how to save the provisioning database from the EMS to a remote server. The remote server must be:

???Connected to a corporate LAN.

???Backed up daily by default, the daily hot backup is not turned on at installation The back up processes:

???ora_hot_backup.ks???Backs up database data files, control files, and archive logs

???ora_arch_backup.ksh???Backs up archive logs

The target backup directory on both primary and secondary EMS systems is /opt/oraback. Backup files in /opt/oraback directory are later transferred to the /opt/backup directory in a remote archive site. After the files are transferred, they are purged from /opt/oraback.

Step 1 Cross check the databases on the primary and secondary EMSs before backing up.

Caution Cross check before ora_hot_backup.ksh and ora_arch_backup.ksh are scheduled. This validates database and archived log files for RMAN processes.

a.Log in as oracle, or su - oracle.

b.Enter dbadm -E backup_crosscheck..

c.Ensure the log file has no errors (except the ???validation failed for archived log??? messages). Ignore these messages of the /data1/arch/opticalx_yyy.arc files because the validation directs RMAN not to look for *.arc files. ora_purge_archlog.ksh purges *.arc files.

RMAN-06157: validation failed for archived log

RMAN-08514: archivelog filename=/data1/arch/optical1_25.arc recid=1 stamp=461878656

Step 2 Remove the archive log purge process and schedule the backup processes.

Note Do this on the primary and secondary EMSs.

a.Disable the ora_purge_archlog.ksh process.

b.Enable the ora_hot_backup.ksh process.

Chapter 3 Monitoring and Backing Up the BTS

Exporting Provisioned Data

c.Optional: Enable the ora_arch_backup.ksh process.

d.Log in as oracle, or su - oracle.

e.Enter crontab ???e.

f.Modify the crontab file as follows. This is on the primary EMS site, database name optical1.

#Daily Oracle Hot backup - this also include archive log backup

#Note: Set hot backup process to run at 2:00am every day.

0 2 * * * /opt/oracle/admin/scripts/ora_hot_backup.ksh optical1 > /opt/oracle/t mp/ora_hot_backup.log 2>&1

#Oracle archive log backups, in addition to daily hot backup.

#Note: Set one additional archive log backup to run at 6:00pm every day.

0 18 * * * /opt/oracle/admin/scripts/ora_arch_backup.ksh optical1 > /opt/ oracle/tmp/ora_arch_backup.log 2>&1

#Purge archive log files

#Note: Delete or uncomment this line to stop purging archive log files.

#0 1,3,???,23 * * * /opt/oracle/admin/scripts/ora_purge_archlog.ksh optical1 > /opt/oracle/tmp/ora_purge_archlog.log 2>&1

g. Repeat Step f by replacing optical1 with optical2 on the secondary EMS site.

Step 3 To setup daily file transfer to the remote archive site using FTP, see Using FTP to Setup File Transfer. To setup daily file transfer to the remote archive site using SFTP, see Using SFTP to Setup File Transfer.

Using FTP to Setup File Transfer

Step 1 Configure the remote site.

a. Verify the oracle user access and create backup directory on FTP server site.

First, test the connection to the remote FTP server using the oracle user access. If the password of oracle is not ???ora00???, update the ORA_PW variable in the /opt/oracle/admin/etc/dba.env file.

b. Do this on the primary and secondary EMSs:

telnet ftpserver

c.Log in as oracle and enter the password (in this case, ora00).

d.Create the /opt/backup directory. Ensure the oracle user has write permission to this directory.

mkdir /opt/backup

Note It is your responsibility to archive backup files from the ftp server /opt/backup directory to a tape device or enterprise tape library.

Chapter 3 Monitoring and Backing Up the BTS

Exporting Provisioned Data

Step 2 Schedule the FTP process.

a.Do this on the primary and secondary EMSs:

b.Add the following line to the Oracle crontab on the primary EMS.

# FTP backup files from primary (optical1) to /opt/backup directory of ftpserver.

0 6 * * * /opt/oracle/admin/scripts/ora_ftp_backup.ksh optical1 ftpserver /opt/backup > /opt/oracle/tmp/ora_ftp_backup.log 2>&1

c.Replace ftpserver with the correct host name of the remote FTP server. Replace /opt/backup with the correct target directory name, if they are different.

Note The 0 6 *** /opt/oracle/admin/scripts/ora_ftp_backup.ksh ?????????

ora_ftp_backup.log 2>&1 are all typed in the same line.

d.Edit the oracle crontab on secondary EMS site by replacing optical1 with optical2.

Step 3 Verify the backup files, enter:

Using SFTP to Setup File Transfer

The following steps generate an SSH key from the primary EMS. Key files are copied to the secondary EMS and remote SFTP server. On the remote SFTP server the "oracle" user is created for login.

Step 1 Generate SSH secure key from primary EMS:

a.Login to the primary EMS:

#su - oracle

#/opt/BTSossh/bin/ssh-keygen -t rsa

b.Generating public/private rsa key pair.

c.Enter file in which to save the key (/opt/orahome/.ssh/id_rsa).

d.Enter passphrase (empty for no passphrase).

e.Enter same passphrase.

Your identification has been saved in /opt/orahome/.ssh/id_rsa. Your public key has been saved in /opt/orahome/.ssh/id_rsa.pub.

The key fingerprint is: d8:4f:b1:8b:f4:ac:2f:78:e9:56:a4:55:56:11:e1:40 oracle@priems79

f.Enter:

#ls -l /opt/orahome/.ssh

Step 2 From the secondary EMS, sftp both "id_ssa" and "id_rsa.pub" files from the primary EMS to the secondary EMS /opt/orahome/.ssh directory. Make the files with "oracle:orainst" ownership.

Step 3 Login to the secondary EMS:

Chapter 3 Monitoring and Backing Up the BTS

Exporting Provisioned Data

#su - oracle

-rw-------1 oracleorainst1675 Mar 10 15:42 id_rsa -rw-r--r--1 oracleorainst397 Mar 10 15:42 id_rsa.pub

Now both primary and secondary EMSs have the same "id_rsa" and "id_rsa.pub" files in

/opt/orahome/.ssh directory.

Step 4 Create an oracle user and /opt/backup directory on the remote SFTP server.

a.Login to remote SFTP server as root.

b.Create a user "oracle" with group "orainst" and home directory "/opt/orahome".

c.Create a repository directory "/opt/backup".

#mkdir -p /opt/orahome

#groupadd orainst

#useradd -g orainst -d /opt/orahome -s /bin/ksh oracle

#chown oracle:orainst /opt/orahome

#passwd oracle

New Password: <Enter password>

Re-enter new Password: <Re-enter password>

#mkdir -p /opt/backup

#chown oracle:orainst /opt/backup

#su - oracle

$ mkdir -p /opt/orahome/.ssh

$ chmod 700 /opt/orahome/.ssh

$ chown oracle:orainst /opt/orahome/.ssh

Step 5 Sftp the "id_rsa" and "id_rsa.pub" files generated in Step 1 to remote SFTP server /opt/orahome/.ssh directory. Make the file owned by "oracle:orainst" owner and group.

Chapter 3 Monitoring and Backing Up the BTS

Archiving Your Database

Step 6 Sftp the "id_rsa" and "id_rsa.pub" files generated in Step 1 to remote SFTP server /opt/orahome/.ssh directory. Make the file owned by "oracle:orainst" owner and group.

Step 7 Test SSH and SFTP from both the primary and secondary EMSs to the remote SFTP server:

a. From BTS primary EMS:

#su - oracle

$ sftp_ping oracle SFTPserverName

Connecting to SFTPserverName...

sftp> quit

SFTP_PING=OK

Note At the first login, the following message may display:"Warning: Permanently added the RSA host key for IP address '10.xx.xxx.xxx' to the list of known hosts."

Step 8 To schedule the ora_sftp_backup.ksh process to execute at 5:30am every day in oracle crontab on both the primary and secondary EMS:

a. Log in as oracle, or su - oracle and enter the following:

crontab -e

b. Add the following line to the Oracle crontab on the primary EMS:

# SFTP backup files from primary (optical1) to /opt/backup directory of SFTPserver.

0 6 * * * /opt/oracle/admin/scripts/ora_sftp_backup.ksh optical1 oracle SFTPserver

/opt/backup > /opt/oracle/tmp/ora_sftp_backup.log 2>&1

Note Enter 0 6 *** /opt/oracle/admin/scripts/ora_sftp_backup.ksh???ora_sftp_backup.log 2>&1 in the same line.

Step 9 Replace SFTPserver with the correct host name of the remote SFTP server.

Step 10 Replace /opt/backup with the correct target directory name, if different.

Step 11 Edit the oracle crontab on secondary EMS site by replacing optical1 with optical2.

Archiving Your Database

Chapter 3 Monitoring and Backing Up the BTS

Archiving Your Database

Step 6 Restore the Solaris ???date??? command to create the system Flash Archive. Enter:

mv /bin/date /bin/date.orig mv /bin/.date /bin/date

Step 7 Create the archive. Enter <hostname>#flarcreate -n <archive name> -x /opt -S -c /mnt/<file

name>

Note Example archive name: flarcreate -n CCPU-EMS -x /opt -S -c /mnt/secems04.archive

Step 8 Back up the /opt directory. Enter tar -cvf - /opt/* |gzip -c >/opt/<hostname_release>.tar.gz

Step 9 Restore the original configuration. Enter:

mv /bin/date /bin/.date

mv /bin/date.orig /bin/date

Step 10 Unmount the NFS server. Enter umount /mnt

Examining Heap Usage

Heap is memory BTS reserves for data it creates as its applications execute. BTS audits heap usage of all the processes started by a platform, CA, AIN, POTS, EMS and BDMS. Heap auditing is added to the ADP process.

When heap usage of a process goes beyond certain threshold level, BTS generates an alarm. The alarm clears when heap usage goes below the threshold level.

Heap audit does the following:

???Monitors traces of heap usage in the last four periods for each process

???Measures heap usage of each process started by the platform once a day at 4 a.m

???Issues a minor alarm if the heap usage of a process exceeds 70% of its max heap size limit

???Clears a minor alarm if the heap usage of a process drops below 68% of its max heap size limit

???Issues a major alarm if the heap usage of a process exceeds 80% its max heap size limit

???Clears a major alarm if the heap usage of a process drops below 78% its max heap size limit

???Issues a critical alarm if the heap usage of a process exceeds 90% its max heap size limit

???Clears a critical alarm if the heap usage of a process drops below 88% its max heap size limit

???Reports, via trace logs, the last twenty heap measurements, including the time and the value for each process

???Clears heap usage alarms when process restarts

Checking the DNS Server

To check the DNS server, do this for all nodes.

Chapter 3 Monitoring and Backing Up the BTS

Log Archive Facility (LAF)

Step 1 Log in as root on the active CA.

Step 2 Enter more /etc/resolv.conf.

Note nameserver <ip address>

Step 3 Enter nslookup

This defaults to the first DNS server.

Step 4 Enter a valid gateway name and press Enter.

An IP address associated to gateway appears.

Step 5 Enter server <second dns server ip>

Step 6 Enter a valid gateway name and press Enter.

An IP address associated to gateway appears.

Step 7 Enter exit to quit.

Log Archive Facility (LAF)

The LAF process in Cisco BTS 10200 transports the trace log files to a remote archive server for storage. LAF is a continuously running daemon process on all nodes (components) of the BTS 10200. It wakes up every minute when active and checks if there are any new log files.

The service provider can specify the external archive system, the target directory, host directory, and the disk quota for each trace log directory in the system. If any new log files are in these trace log directories, LAF transfers them by Secure FTP (SFTP) to an external archive server specified by the service provider.

Secure Transfer of Files

BTS 10200 uses Secure FTP to transfer trace log files to the external server. LAF opens an SFTP connection when its ready to transfer log file to the remote server. This connection is not closed even after the transfer is complete. If for some reason the connection closes, the LAF process re-establishes the connection during the next transfer. The connection is persistent till the LAF feature is disabled.

LAF operates on a single SFTP connection and transfer of files occurs one file at a time (using the SFTP put operation). The same connection is used to transfer multiple files. When the LAF process detects a bad connection, it terminates the SFTP session by closing the socket used to talk to the archive server.

The LAF process maintains a linked list for the files that need to be transferred. If the connection is lost during a transfer, the LAF process moves the unsuccessfully transferred file to the end of the list and raises Maintenance Alarm 108.

A re-attempt on a failed file depends on the number of files in the list and the time taken to transfer those files. When there is no file to be transferred (i.e. the list is empty), then there is a gap of 30 seconds before processing the list again.

The LAF process increments a counter, which is specifically used for the number of times the transfer was attempted for this file. If a counter is more than three, the log file is deleted from the list. That is, upon three failed attempts on the same file, the file entry is deleted from the list.

Chapter 3 Monitoring and Backing Up the BTS

Log Archive Facility (LAF)

Other Capabilities

This section lists the additional capabilities of the LAF process.

???It performs disk space management when 90% of the disk space quota specified for the target directory is reached.

???It gracefully recovers from any abnormal conditions and re-initiates the process to continue the transfer of files.

???It generates alarms when any unsuccessful scenarios are encountered. These alarms are listed in the

Cisco BTS 10200 Troubleshooting Guide.

Provisioning LAF

Caution The values provided by the user for the following parameters will be written into /etc/opticall.cfg file and transported to all the four BTS 10200 nodes.

The following parameters are associated with the LAF process. If they are left blank, the LAF process for a particular platform (such as, CA, FSPTC, FSAIN) is turned off.

To use this feature, you must provision the following parameters with the external archive system, the target directory, and the disk quota (in GB) for each platform.

CAxxx_LAF_PARAMETER

FSPTCxxx_LAF_PARAMETER

FSAINxxx_LAF_PARAMETER

Note that xxx must be replaced with each platform???s instance number.

Example 1

CA146_LAF_PARAMETER="yensid /CA146_trace_log 20"

Example 2

FSPTC235_LAF_PARAMETER="yensid /FSPTC235_trace_log 20"

Example 3

FSAIN205_LAF_PARAMETER="yensid /FSAIN205_trace_log 20"

To enable Log Archive Facility (LAF) process, refer to Enabling LAF Process section.

Enabling LAF Process

To enable the Log Archive Facility (LAF) feature, you must set up the authorization for non-interactive SSH login to the external archive server for the Cisco BTS 10200 system to access and turn the LAF processes to active state. (Immediately after the fresh installation and platform start, the LAF process is in a dormant state).

Chapter 3 Monitoring and Backing Up the BTS

Log Archive Facility (LAF)

The steps to set up the authorization in external archive server and turn the LAF processes to active is listed below:

Setup Non-Interactive SSH Login to External Archive Server

Note The external archive system is recommended to be located such that it can be accessed by the management network. In such a case, the static routes in the CA system should be explicitly set so that the traffic to the external archive system is routed through the management network see section (???Adding Static Routes??? section for more details). Otherwise, the traffic is routed through the default network (i.e. signaling network) and may not be able to reach the external archive system.

Step 1 Log in to the Cisco BTS 10200 primary EMS as root.

Step 2 From the EMS, login to the external archive server via ssh to get the external archive server added to the

/.ssh/known_hosts file.

Step 3 Log off from the external archive server.

Step 4 While still logged in on the primary EMS as root, generate an SSH key.

a.Execute cd /opt/BTSossh/bin.

b.Execute ssh-keygen -t rsa.

c.Press Enter to accept the default file name for the key (/.ssh/id_rsa).

d.Enter y if prompted to choose whether to overwrite the existing file.

e.Press Enter when prompted to enter a passphrase (i.e. no passphrase).

f.Transfer the resulting file (/.ssh/id_rsa.pub) to a temporary location on the external archive server.

Step 5 Set up the external archive server with the key generated in Step 4.

a.Login to the external archive system as root.

b.If a /.ssh/authorized_keys file does not exist on the external archive system, rename the id_rsa.pub file (copied from the Cisco BTS 10200 EMS) to /.ssh/authorized_keys. If the file does exist, append the id_rsa.pub file to it.

Step 6 On the primary EMS, execute

ssh root@abcd

where abcd is the IP address or fully-qualified domain name of the external archive server.

Step 7 Verify that login to the external archive server is successful and that no prompts for username or password are issued.

Step 8 Run enableLAF in EMS platform directories (i.e. /opt/ems/bin and /opt/bdms/bin)

Step 9 Repeat Steps 1-8 for the secondary EMS, primary CA and secondary CA. (In CA, the platform directories are /opt/OptiCall/CAxxx/bin, /opt/OptiCall/FSPTCyyy/bin, /opt/OptiCall/FSAINzzz/bin).

Note Billing has a similar mechanism/steps to SFTP their Call Detail Blocks (CDB) files to an external machine. If the LAF and Billing use the same target machine, then in both EMS, perform Steps 1-7 only once. You must still run Step 8 to enable LAF. And you must still run Steps 1 -9 in CA nodes.

Chapter 3 Monitoring and Backing Up the BTS

Moving Core Files

Adding Static Routes

To add static routes to all Cisco BTS 10200 systems, perform the following steps:

Step 1 From the shell or window of the primary call agent, change directory to /opt/utils.

cd /opt/utils

Step 2 Edit S96StaticRoutes using an editor.

Step 3 Add the subnet of NTP server, DNS server, external archive server and any other machine to the file, which user wants to have access to Cisco BTS 10200 system in the following format:

route add -net <destination network> <network gateway>

Note All NTP, DNS traffic, traffic to external archive server, and traffic from other machine to Cisco BTS 10200 system (eg. login), should all go through management networks. (i.e. network gateway in management network). This is particularly important in CA system because CA has both management and signaling network. If user does not specify explicitly in this file, those traffic will be directed to signaling network, because signaling network is the default one in CA/FS.

Step 4 Make sure there is a soft link pointing from /etc/rc3.d/S96StaticRoutes to /opt/utils/S96StaticRoutes.

ls -l /etc/rc3.d/S96StaticRoutes

Step 5 After editing, close the file, and run S96StaticRoutes.

/etc/rc3.d/S96StaticRoutes

Step 6 Repeat Step 1 to Step 5 on the secondary CA.

Step 7 Verify the connectivity by pinging the DNS server, NTP server, external archive server, or any machine that user just added in that file.

LAF Alarm Information

Refer to the following link to see the LAF alarm information.

Cisco BTS 10200 Troubleshooting Guide http://www.cisco.com/en/US/docs/voice_ip_comm/bts/ 6.0/troubleshooting/guide/07tg01.html#wp1938289

Moving Core Files

BTS creates and stores core files in the bin directory for the binary executable that generated the core. Core files are large (2???4 GB) and eventually cause a disk full condition resulting in a switchover. When a BTS platform system generates a core file, the BTS creates an alarm. The Core File Present???Audit 25 (major) alarm indicates a core is present in the BTS. The primary cause of this alarm is that a network element process crashed.

C H A P T E R 4

Operating the BTS

Revised: February 18, 2010, OL-16000-07

Introduction

This chapter tells you how to operate the BTS. This chapter assumes the following are true:

???Connecting components have been correctly installed.

???Connecting components have been successfully started.

???You are a system administrator with past BTS experience.

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 4 Operating the BTS

Viewing Calls

These tasks allows you to view information related to call forwarding features.

If A calls B and the call is forwarded to C:

???Querying A shows A is connected to C and provide C's information.

???Querying C shows C is connected to A and provide A's information.

???Querying B shows A is calling C and the call is forwarded through B.

???Even when the call is forwarded through B, B can originate another call. B can also forward multiple calls.

When viewing Three-Way Call and Call Waiting calls remember the output shows both calls.

Table 4-2 Viewing Calls

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 4 Operating the BTS

Using Show and Change Commmands

Table 4-4 Using Show and Change Commands

Using ERAC Commands

Using prepared SQL statements Extended Read Access Commands (ERAC) commands perform a complex read against the BTS database. This SQL optimization and multitable and nested SELECT(s) quickly return data that would otherwise take several database dips and a lot of back end data post processing. Use the following interfaces to access ERAC:

???CLI and MAINT shells

???CORBA/XML adapters

???EPOM (uses CORBA/XML)

???SPA

Directory number (DN) and telephone number (TN) refer to the same BTS entity but with different sources:

???TN???EC database value + the Office Code table???s NDC field

???DN???DN2 Subscriber table???s DN field

The TN/DN is a concatenation of 14 (or less) digits. Commands fail if a partial TN is supplied.

Note Commands allow for wild card support. When you enter a subscriber, subscriber account code, or DN , the value can have the wild card percent (%) search criteria.

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 4 Operating the BTS

Scheduling Commands

Table 4-5 Viewing and Deleting Transactions (continued)

Scheduling Commands

The Hour and Minute Command Scheduling feature allows you to schedule command execution for a specific hour and minute.

Using start-time and recurrence command tokens, schedule command time and frequency (hourly, daily, weekly, monthly, etc.). You can remove the command at any time; if it is recurring and currently executing, it completes and is removed.

Limitations

To prevent overload and subsequent EMS degradation, limit commands to 10, each taking less than a minute.

If you schedule a command to execute, but an earlier occurence of that command is still executing, the second might fail.

Table 4-6 Scheduling Commands

C H A P T E R 5

Managing External Resources

Revised: February 18, 2010, OL-16000-07

Introduction

This chapter tells you how to manage external resources provisioned on the BTS using administrative (ADM) commands. External resources have two service states:

???Administrative???State the BTS user provisions for the resource link

???Operational???Physical condition of the resource link or the resource) The two types of service states are independent of each other, for example:

A user places an MGW link in-service; its administrative state is ADMIN_INS. But that link between the BTS and MGW is lost. The MGW link???s operational state is MGW_STATUS_DOWN. A query of the MGW returns both the administrative state and operational state.

Viewing BTS System-Wide Status

BTSSTAT runs on any BTS host. Any valid UNIX user can enter btsstat from a UNIX shell to initiate it. This command returns the following for all BTS components:

???Component id

???Side

???Host name

???Version

???Replication status

???Redundancy status

To run BTSSTAT from a non-BTS host, the configuration file needs the information in following table. BTSSTAT ignores all other lines in the file.

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 5 Managing External Resources

Managing Subscriber Terminations

Table 5-5 Managing Subscriber Terminations

For more information use one of the following for oper-state:

???FA???Faulty

???NF???Not faulty

???IDLE???Termination idle

???ACTIVE???Termination active

???DOWN???Termination down

???TERM-FA???Termination fault

???TEMP-DOWN???Termination temporarily down

???UNREACH???Termination unreachable

???INT-MAINT???Termination internal maintenance

???UEQP???Termination unequipped

???ALL???All states, same as executing command without oper-state token

Chapter 5 Managing External Resources

Learning External Resource Dependencies

Table 5-9 Managing External Resources (continued)

where 1=secondary record-type

3.On the secondary EMS enter <hostname>#df ???k

4.Ensure the /opt directory is not more than 70% full.

If the /opt directory is >70% full, remove obsolete scripting files and other user-generated files. Also remove obsolete files from the backup directory. For help call Cisco TAC.

Learning External Resource Dependencies

Chapter 5 Managing External Resources

Learning External Resource Dependencies

Figure 5-2 Administrative and Operational Maintenance States for Residential Gateways

P_OOS = Place out of service P_INS = Place in service P_MNT = Place maintenance NP = Not provisioned

SL = Suscriber line

If SL = INS warn else {

{if SL = OOS discover SL*2} init SL*3,

SL = INS}

Warning

If SL = MNT warn else {

{if SL = OOS discover SL*2} init SL*3,

SL = MNT}

* Provisioning command

*2 Establish MGCP communication with subscriber loop

*3 Determine capabilities and program terminations

Chapter 5 Managing External Resources

Learning External Resource Dependencies

Figure 5-3 ISDN Administrative and Operational Maintenance States for a Trunking Gateway

Add (TRK, TGP)

if TGP = OOS add (TRK)

TRK = OOS

TGW = OOS

TGP = NP/OOS

TRK = NP/OOS

P_OOS = Place out of service P_INS = Place in service P_MNT = Place maintenance

NP = Not provisioned

Del (TRK, TGP)

if (TRK, TGP) = OOS del (TRK, TGP)

P_OOS (TGP)

if TGP!=MNT

TGP=OOS all TRK=OOS bearer=OOS signaling=OOS

52079

Chapter 5 Managing External Resources

Learning External Resource Dependencies

Add (TRK, TGP)

if TGP = OOS add (TRK)

TRK = OOS

TGW = OOS

TGP = NP/OOS

TRK = NP/OOS

P_OOS = Place out of service P_INS = Place in service P_MNT = Place maintenance

NP = Not provisioned

Del (TRK, TGP)

if (TRK, TGP) = OOS del (TRK, TGP)

P_OOS (TGP)

if TGP!=MNT

TGP=OOS all TRK=OOS bearer=OOS signaling=OOS

52079

Chapter 5 Managing External Resources

GigE Support

Caution

The purpose of implementing the GigE Support Feature provisioning is to increase the bandwidth between the network switches and the Cisco BTS 10200 from 100 Mbps to 1000 Mbps.

This section describes the steps needed to enable GigE support on the UNIX hosts of the

Cisco BTS 10200 Softswitch. Use this procedure only after you upgrade to Cisco BTS 10200 Release 6.0(1) or later.

This is not an upgrade procedure. Performing the steps in this procedure will bring the Cisco BTS 10200 down on one side with temporary loss of redundancy. Do not start this procedure unless you have authorization from your supervisor. If you have questions, contact Cisco Technical Assistance Center (TAC).

Perform this procedure on one UNIX host at a time.

This procedure should be executed by a person very familiar with the operation and administration of the Cisco BTS 10200 and 29xx switches as well as the network and cabling of the Cisco BTS 10200.

Prerequisites

1.The Cisco BTS 10200 Softswitch Release 6.0(1) must already be installed.

2.The BTS 10200 UNIX host must have network interfaces capable of running at GigE speed (1000 Mbps).

Provisioning the GigE Interface

For each host in Cisco BTS 10200, perform the following steps:

Step 1 Ensure that the targeted Cisco BTS 10200 applications are operating in standby mode. These applications include the Call Agent (CA), the Feature Server for POTS, Tandem, and Centrex services (FSPTC), the Feature Server for AIN services (FSAIN), the Element Management System (EMS), and the Bulk Data Management System (BDMS). If necessary, perform a switchover to ensure this is the case.

Step 2 Use the platform stop all command to stop the targeted Cisco BTS 10200 applications running on the UNIX host.

Step 3 Identify and note the Ethernet ports on the 29xx switches that connect to the Cisco BTS 10200 UNIX host.

Step 4 Modify the configuration of the switch ports connected to the Cisco BTS 10200 UNIX host to auto negotiate. To do so, first log in to the 29xx switch through console access, change to the switch port, and modify the speed and duplex mode settings on each port using the following commands:

no speed 100 no duplex full

Chapter 5 Managing External Resources

Provisioning the GigE Interface

shut

no shut

Step 5 Save the switch configuration.

Step 6 Reboot the Cisco BTS 10200 host using the shutdown -g0 -y -i6 command. We recommend that you execute the shutdown command using the console port to avoid loss of connectivity during the reboot. After the reboot, all the targeted Cisco BTS 10200 applications should automatically restart and go into standby state.

Step 7 Verify interface speed and duplex mode by executing the following command on the host:

dladm show-dev

Example output:

ca102> dladm show-dev

bge0 link: up speed: 1000 Mbps duplex: full

bge1 link: up speed: 1000 Mbps duplex: full

bge2 link: up speed: 1000 Mbps duplex: full

bge3 link: up speed: 1000 Mbps duplex: full

Step 8 Repeat for the other UNIX hosts in the Cisco BTS 10200 system.

C H A P T E R 6

Using BTS Measurements

Revised: February 18, 2010, OL-16000-07

Introduction

This chapter describes BTS traffic measurements and tells you how to use them. BTS does the following:

???Collects statistics in 5-, 15-, 30-, or 60-minute intervals.

???Collects TG statistics at 100 second intervals.

???Clears measurements after each interval without loss of ongoing counts.

???Saves 48 hours of statistical data in 5-, 15-, 30-, or 60-minute increments in persistent store.

???Displays of summary report of past 48-hour period.

???Provides 0n-demand report queries keyed by collection interval.

???Issues events.

There are many measurement types, but they all have a similar format. Only titles and measurement labels differ. Each header tells you where the data is from and whether it is normal or suspect.

Access BTS measurements using the following:

???Command-line interface (CLI), which runs over a telnet or secure shell (SSH) session.

???Comma-separated value (CSV) or Extensible Markup Language (XML) format via FTP or SFTP interface.

???SNMP MIB (version v2c).

Measurements without data for the given interval do not appear in reports.

Using Measurements

When working with measurements watch for the following:

???rapid buildup of counts???Sometimes that means congestion or processing failures.

???disparity in measurement pairs that are normally equal???The greater the difference between the two, the more likely there is a problem. For example, successful incoming messages should be nearly equal to incoming messages:

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 6 Using BTS Measurements

Learning the Measurement Types

SIP_TOTAL_INCOMING_MSG and

SIP_TOTAL_SUCCESS_INCOMING_MSG

Table 6-1 Using Measurements

Reporting historical measurements report measurement-sim-summary start-time=2003-03-27 10:00:00; end-time=2003-03-27 12:00:00; call-agent-id=CA146; output=sim-report; output-type=csv;

Learning the Measurement Types

These tables list the different measurement types the BTS collects.

ISDN Measurements

Table 6-2 ISDN Measurements

C H A P T E R 7

Using the BTS SNMP Agent

Revised: February 18, 2010, OL-16000-07

Introduction

This chapter explains how to use the Simple Network Management Protocol (SNMP) agent.

The BTS uses a SNMP agent to communicate with a service provider???s network management system (NMS). Working together, the SNMP agent and NMS monitor and control BTS components on the managed network. The NMS does most of the processing and provides the majority of memory resources. The SNMP agent collects statistical data (traffic measurements) for the following BTS components:

Using the SNMP agent a user can do the following:

???View and change the status of individual BTS components

???View and change the status of a group of BTS components

???View SNMP trap (alarm) reports

Managing User Access to the SNMP Agent

The SNMP agent has access levels. Tasks you can perform depend both on your user group (community) and CLI security privileges.

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 7 Using the BTS SNMP Agent

Viewing SNMP Trap Reports

Table 7-1 Managing SNMP Agent Access

Viewing SNMP Trap Reports

The SNMP agent sends traps to the NMS; each trap maps to an EMS alarm. Alarms not mapped to a specific trap map to a generic trap. Traps show you the following, depending on information availability:

???Severity level

???Alarm ID associated with the trap

???Alarm category

???Set/Cleared flag

???Component (instance) ID

???Component type

???Details of the trap

???Time that trap was generated

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Chapter 7 Using the BTS SNMP Agent

Enabling NMS to Query/Poll Solaris SNMP Agent

Note

The active EMS node runs the SAD process, which converts the BTS 10200 specific events/alarms into SNMP traps and sends them to the configured SNMP Trap listeners or the NMSes. The SAD process handles the SNMPWALK/GET/GETNEXT/SET on the OIDs that are defined in the opticall.mib file. The SAD process also runs on the standby EMS, but does not perform any function.

The SAD process does not run on the CA nodes.

The CA runs only the standard Solaris SNMP agent.

The standard Solaris SNMP agent runs on both the active and standby EMS and CA nodes. Therefore, all the four nodes generate the solaris-level traps. The name of the standard Solaris SNMP agent is mibiisa, which runs on port number 13230. The Solaris SNMP agent can be used to collect the sun box related statistics and/or traps. Note that the mibiisa supports only those OIDs (object identifiers) that are defined in the SUN MIB.

Note The active/standby EMS and active/standby CA nodes generate the solaris-level traps, whereas only the active EMS generates BTS-specific traps and sends them to NMS. The NMS can query/poll all the four nodes to receive the generated traps.

To enable the NMS to directly query the Solaris SNMP agent for a range of OIDs specified by SUN MIBs, and receive Solaris box-level traps, do the following:

1.Open the /etc/snmp/conf/snmpd.conf file.

2.Define the read-community as ???public???.

3.In the ???Managers??? field, enter the IP address or hostname of the NMS from where the user needs to send the SNMP query. Enter multiple addresses separated by spaces, but leave the ???localhost??? entry as is.

4.In the Trap field, configure the IP address or hostname of the NMS where the traps have to be sent.

5.Restart the SNMP agent, enter:

/etc/init.d/S98mibiisa stop

/etc/init.d/S98mibiisa start

6.Query the SNMP agent (using SNMPGET/SNMPWALK) from the Manager using the read-community and port 13230. For example, to get the system up time, enter the following command:

snmpwalk -c public -p 13230 prica07 system

The output appears as given below:

system.sysDescr.0 = Sun SNMP Agent system.sysObjectID.0 = OID: enterprises.42.2.1.1

system.sysUpTime.0 = Timeticks: (279199168) 32 days, 7:33:11.68 system.sysContact.0 = System administrator

system.sysName.0 = prica07

system.sysLocation.0 = System administrators office system.sysServices.0 = 72

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Appendix A Feature Tones

Tone Frequencies and Cadences

1.When more than one condition is listed for a single tone, any one of the conditions can cause the tone to be played.

2.For more information on the screening list, refer to the Cisco BTS 10200 Softswitch System Description.

3.MWI = message waiting indicator; VMWI = visual message waiting indicator.

Tone Frequencies and Cadences

Tones are requested by the BTS and delivered to the subscriber or operator by the MGW. Some MGWs can be provisioned to play tone cadences different than the ones described in this table.

Appendix A Feature Tones

Tone Frequencies and Cadences

1. BLV = busy line verification

Table A-3 lists the maintenance tones used for continuity testing. See the Telcordia document

GR-317-CORE for additional details.

Table A-3 Maintenance Tone Descriptions

All tones are based on information in the following:

???Telcordia document GR-506-CORE, Signaling for Analog Interfaces

???Telcordia document TR-NWT-506, Issue 3, Signaling

???Telcordia document GR-590-CORE, Call Pickup Features (FSD 01-02-2800)

???Telcordia document GR-317-CORE, Switching System Generic Requirements for Call Control Using the Integrated Services Digital Network User Part (ISDNUP)

???Telcordia document GR-219-CORE, Distinctive Ringing/Call Waiting (FSD 01-01-1110).

???IETF document RFC 2705, Media Gateway Control Protocol (MGCP) Version 1.0

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

A P P E N D I X B

FIM/XML

Revised: February 18, 2010, OL-16000-07

This appendix describes the FIM/XML feature for Release 6.0.1 of the Cisco BTS 10200 Softswitch and explains how to use it. This document includes the following topics:

???Understanding the Configurable FIM/XML Feature

???Tool Requirements

???Writing an External FIM/XML File

???Defining Features

???Installing the FIM/XML File Using the Offline FIM/XML Tool

???FIM/XML File and Shared iFC File

???Provisioning iFC

???Feature Restrictions and Limitations

Understanding the Configurable FIM/XML Feature

The Cisco BTS 10200 supports a Feature Interaction Module/Extensible Markup Language (FIM/XML) file that defines the interactions between the internal features (for example, Call Waiting, Call Forwarding) and external features (features that reside on application servers that interact with

Cisco BTS 10200 and SIP triggers like, TV Caller ID, Network Address Book).

However, the current FIM/XML format can be time consuming as the service provider or operator needs to configure and define large number of parameters. The configurable FIM/XML feature introduces a new external configurable FIM/XML file which is more efficient because it defines the interactions between the IMS Service Control Interface (ISC) and Feature Control Protocol (FCP) features. The Cisco BTS 10200 Feature Server manages the ISC and FCP feature interactions based on the rules in this FIM/XML file.

The Cisco BTS 10200 Softswitch Plain Old Telephone Service (POTS) Feature Server uses the configurable FIM/XML file to manage the ISC and FCP features using the parameters defined in the configurable FIM/XML file. You can produce the new FIM/XML file using the old FIM/XML file and schema data.

External FIM/XML file allows you to do the following:

???Add a new external feature name

???Specify the list of features inhibited by an external feature

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Appendix B FIM/XML

Tool Requirements

???Specify the precedence order for the external features

???Define the list of features that inhibit the external feature

???Define error response operations

Advantages of the FIM/XML Tool

The FIM/XML tool enables the service provider or operator to specify the SIP trigger-based features. The SIP trigger-based feature examples are, Off-Hook Delay Trigger (OHD), Termination Attempt Triggers TAT-1 and TAT-2.

The tool helps to define the interactions and precedence with the other features of Cisco BTS 10200. The service provider can generate his or her own XML file (FIM/XML) according to the schema data provided in the Cisco BTS 10200. Once the generated FIM/XML file is installed on the

Cisco BTS 10200, the new external application server-driven features and their interactions with other Cisco BTS 10200 features comes into effect.

The advantages of the FIM/XML tool are:

???The tool prevents the operator from the possibility of disrupting the external/current features when editing the complex FIM/XML file. The FIM/XML tool now provides an easy and efficient way of editing the complex file seamlessly.

???Provides a semantic check on the operator-generated FIM/XML file.

In order to specify a common SIP trigger profile, an additional XML file needs to be generated. This XML file calls the Shared Initial Filter Criteria (iFC) XML file read by Cisco BTS 10200 to determine the SIP trigger profiles. SIP trigger profiles are used to determine the address of the application server and populate the different route-headers when SIP triggers launch. For additional information on the shared iFC file, refer to the ???FIM/XML File and Shared iFC File??? section on page B-9.

Tool Requirements

Each Cisco BTS 10200 release includes an original FIM/XML file. The offline FIM/XML tool allows the service provider or operator to define a new external feature or modify existing interactions involving the ISC features.

The Cisco BTS 10200 must meet the following conditions and requirements for the FIM/XML tool:

???Java Virtual Machine (JVM) 1.6 or above is installed on the system.

???All three input files (for example param=1, param=2, and param=3) are present in the same directory as the tool .jar file. Refer to Step 6 in the procedure below for the list of input files.

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Appendix B FIM/XML

Writing an External FIM/XML File

???The service provider or operator has write permission for the directory where the FIM/XML offline tool is located.

???The service provider or operator has read permission for all the input XML files.

Writing an External FIM/XML File

To write an external FIM/XML file, do the following:

Step 1 Use any XML editor.

Step 2 Open a new XML file in it.

Step 3 Set the schema to the supplied External FIM/XML schema:

<external-fimxml xsi:schemaLocation="externalfimxml externalfimxml.xsd" xmlns="externalfimxml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

Step 4 Define new features in XML file.

Step 5 Save the new external FIM/XML file.

Defining Features

The service provider needs to define new features to ensure that Cisco BTS10200 understands the behavior of the external features. The external feature is defined using the define-external tag in the External FIM/XML file:

<define-external feature-name="TAT_5???feature-type="TERMINATING"> </define-external>

Each external feature has a unique name. The name has a minimum of 16 characters, and no special characters are allowed. The Feature Type is defined as Originating or Terminating.

Elements in the External FIM/XML File

The external FIM/XML is a subset of the FIM/XML file and contains definitions and behavior of ISC features. The External FIM/XML file is used to define the ISC feature and its properties. The defined external elements are used to add new external features to Plain Old Telephone System (POTS) FC.

The external FIM/XML file contains the following elements:

??????Define Element??? section on page B-4

??????Precedence-Exception Element??? section on page B-4

??????Inhibit Others Element??? section on page B-5

??????Inhibit Me Element??? section on page B-5

??????Response Profile Element??? section on page B-5

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Appendix B FIM/XML

Defining Features

Define Element

The properties of the external feature are configured in the Define Element. The FIM/XML tool processes the external FIM/XML file in the Define Element.

<define-external feature-name="TAT_1" precedence_lesser_than ="SCR" billing-name="tat1_as">

Table 1 lists the attributes in the Define Element.

Precedence-Exception Element

The Precedence-Exception element defines the exception in the precedence list for the defined external feature. The feature name in the precedence-exception element has a lesser precedence than the defined external feature even after the external feature is defined below it in the precedence list.

The following is the example to define precedence exception:

<define-external feature-name=???F5??? precedence-lesser-than=???F4??? > <precedence-exception feature-name=???F2"/>

???. </define-external>

You can have as many exceptions for the precedence as you like (for example, F1>F2>F3>F4>F5>F2, where you can define F5 precedence less than F4 and greater than F2).

Table 2 lists the attributes of the Precedence-Exception Element.

The FIM/XML tool expects the Precedence-Exception element in External FIM/XML file as follows.

<precedence-exception feature-name="CCW" />

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Appendix B FIM/XML

Defining Features

Inhibit Others Element

The Inhibit Others Element tag defines the list of features that are inhibited when a given feature is in an Assigned or Invoked state. Table 3 lists the attributes of the Inhibit Others Element.

Feature Inhibitions prevent invocation of a given feature if a specified feature is Activated, Deactivated, Invoked, Assigned. For example, when the emergency call is involved then the Call Waiting is inhibited.

The FIM/XML tool expects the defined element in the External FIM/XML file as indicated in the following sections.

<inhibit-others state="ASSIGNED" feature-name="CNAM"/> <inhibit-others state="INVOKED" feature-name="MOH"/>

Inhibit Me Element

The Inhibit Me element defines the list of features that inhibit the external feature when the features are in the following states: Activated, Deactivated, Assigned, or Invoked. Table 4 lists the attributes of the Inhibit Me Element.

The FIM/XML tool expects the defined element in the External FIM/XML file as indicated in the following sections.

<inhibit-me feature-name="CCW" state="DEACTIVATED"/> <inhibit-me feature-name="CW" state="INVOKED"/>

Response Profile Element

When the defined external feature is invoked, the system receives different responses or errors, depending on what happened during the feature invocation. This allows the operator to specify what actions need to be taken when specific errors or responses (SIP Responses) are received from the Application Servers.

For example, when an external feature is invoked, an INVITE is sent by Cisco BTS 10200 to the Application Server and no application server can return an error response such as ???401 unauthorised??? error. You can define the action that Cisco BTS 10200 can take using the Response Profile element.

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Appendix B FIM/XML

Defining Features

Error

The list of error elements is matched one by one to see if the error response received during the external feature invocation falls within its specified range. When a match is found, the error handling operation specified within the respective error element is executed.

Operation

This element specifies the action taken when the response condition matches the error element. The parameters of an element can be a list of name or value pairs specified by parameter elements.

The FIM/XML tool processes the defined element in the External FIM/XML file as indicated in the following sections.

<response-profile>

</error>

</error> </response-profile>

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Appendix B FIM/XML

Installing the FIM/XML File Using the Offline FIM/XML Tool

Each Cisco BTS 10200 release includes an original FIM/XML file that is installed during system setup and upgrades. The offline FIM/XML tool allows the service provider to define a new external feature or modify existing interactions involving the ISC features. In order to enable the service provider to add external features, a separate XML configuration file is provided. This new FIM/XML file is called an External FIM/XML file. After the operator generates the external FIM/XML file according to the schema provided, the FIM/XML tool generates the FIM/XML file. Use this file as input, along with the schema, to produce the new FIM/XML file with the offline tool. The offline tool is the XML file that is separate from the Cisco BTS 10200.

Note The system must meet the tool conditions and requirements for the FIM/XML tool as described in ???Tool Requirements??? section on page B-2.

The following procedure describes how to generate the configurable FIM/XML file using the offline FIM/XML tool.

Step 1 Obtain the fiexmxml.zip file from the location specified and then unzip the FIM/XML file on all BTS nodes:

/opt/OptiCall/tools/fiexmxml.zip

Step 2 Run the fimxml.zip file.

The external FIM/XML template is external.xml and the external FIM/XML schema is obtained as externalfimxml.xsd:

hrn29priems:/opt/OptiCall/tools >unzip fimxml.zip Archive: fimxml.zip

inflating: config.xml

inflating: external.xml

inflating: externalfimxml.xsd

inflating: fimxmlconfig.xsd

inflating: FIMXML.xsd

inflating: fimxml.jar hrn29priems:/opt/OptiCall/tools

Step 3 Use any XML editor to create an external FIM/XML file based on the rules from the externalfimxmlfile.xsd schema file provided by the Cisco BTS 10200 during installation. The service provider cannot modify the schema data.

Step 4 Use the XML editor to edit a sample file provided with the FIM/XML tool. This file becomes the offline FIM/XML configuration file used in Step 6.

Step 5 You can edit the FIM/XML file so that the emergency features such as 9-1-1, Hostage Negotiation, and Emergency Callback (ECB) cannot be inhibited by the operator after the configurable FIM/XML file is downloaded to the Cisco BTS 10200:

<fcp-features> <feature name=E911 inhibition-allowed=false/>

You can also configure the schema path for the configurable FIM/XML file:

<config-param param=FIMXMLSCHEMA_PATH value=FIMXML.xsd/>

If you do not specify a schema path, the Cisco BTS 10200 uses the following default path:

/opt/OptiCall/potsctx/bin/FIMXML.xsd

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Appendix B FIM/XML

Installing the FIM/XML File Using the Offline FIM/XML Tool

Step 6 Run the following Java application:

java ???jar fimxml.jar param1 param2 param3 param4

Where

???param1 = the name of the external FIM/XML file described in Step 3

???param2 = the name of the original FIM/XML file produced during the Cisco BTS 10200 installation. Copy this file from the following path: /opt/OptiCall/etc/fimxml/FSPTC235/FIMXMLRules.xml.

???param3 = the name of the configuration file described in Step 4

???param4 = the name of the configurable file to be generated (defaults to merged.xml). This parameter is optional.

If the script runs successfully, the tool returns the following message SUCCESS!! New FIM/XML generated at path <path>. The successfully generated configurable FIM/XML files are copied or FTP to the EMS.

If the script does not complete successfully, the system returns a non-zero value and generates a log file which is copied to the same directory as the FIM/XML tool .jar file.

Note The tool produces log files for both successful and unsuccessful attempts.

Note You can troubleshoot the errors from the descriptions provided with the error messages.

Step 7 Run the following command from the EMS:

install fimxml file_name=<absolute_path>

This command does the following:

???Processes the configurable FIM/XML file on the EMS

???Adds, updates and/or deletes the external feature names from the new fimxml file.

???Copies the new file to the following path:

/opt/OptiCall/etc/fimxml/FSPTC235/FIMXMLRules.xml

Step 8 Restart the POTS Feature Server on both the CA primary and secondary nodes to load the configurable FIM/XML file.

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Appendix B FIM/XML

FIM/XML File and Shared iFC File

A Shared Initial Filter Criteria (iFC) file specifies all the data required to provision a new feature in the Element Management System (EMS). Using the shared iFC file is analogous to provisioning feature data through the CLI. You can provision all the user commands supported through CLI using the shared iFC.

The Cisco BTS 10200 supports the following commands through shared iFC:

???Add/change/delete feature

???Add/change/delete feature-config fname

???Add/ change/delete vsc

???Add/change/delete sip-trigger-profile

???Add/Change/delete subscriber-sip-trigger-profile

???Add/Change/Delete service

???Add/Change/Delete subscriber-service-profile

The following conditions apply to the configurable FIM/XML file and the shared iFC file:

???Any property provisionable through FIM/XML cannot be provisioned through the shared iFC file.

???If an external feature name exists in the FIM/XML file but is not defined in the EMS, then the EMS provisions that external-feature name by reading the FIM/XML file.

Features Defined in FIM/XML and Shared iFC

The Shared iFC file defines the features invoked by Cisco BTS 10200. The FIM/XML defines the information pertaining to interactions between these features.

Table 7 explains the parameter names that can be configured in the FIM/XML and Shared iFC.

Cisco BTS 10200 Softswitch Operations and Maintenance Guide, Release 6.0.x

Appendix B FIM/XML

Provisioning iFC

To enable the operator to provision iFC (s) through the XML file, the service provider must generate and install the new XML file (Shared iFC file).

The XML file allows the operator to provision iFC (s) by allowing

???External feature definition

???Vertical Service Code (VSC) to feature mapping by defining a star-code if necessary for invoking an external Application Server-driven feature

???SIP trigger profile specifies which application server needs to be contacted and how to populate the Route-headers

???Sip Trigger Profiles (Subscriber Specific)

The XML file enables the operator to define the mapping of one sip_trigger_profile to multiple subscribers. The following commands list the CLI commands corresponding to entries in the Shared iFC file:

???Defining a New feature as the Originating Feature.

???Defining a VSC

Defining a New feature as the Originating Feature

This command defines the new feature as the originating feature.

add/change feature fname=ABC; tdp1=collected_information; tid1=ohd_trigger; ttype1=R; tdp2=o_exception; tid2=reroute_trigger; ttype2=R; tdp3=collected_information; tid3=vertical_service; ttype3=R; feature_server_id=FSPTC235;

Defining a VSC

This command defines a VSC which when dialed invokes the external feature.

add/change vsc digit-string=*72;fname=ABC;

Defining the SIP Trigger Profile

This command defines the SIP Trigger Profile used with the external feature.

add sip-trigger-profile id=vdial+noivr;

route_guide_id=60001;AS_ROUTE_HEADER_USER=vdial+noivr;

Feature Configuration

This command defines the feature configuration.

add feature-config fname=ABC; type=DEFAULT-SIP-TRIGGER-PROFILE; value=AS_1;

Appendix B FIM/XML

Feature Restrictions and Limitations

Subscriber-Sip-Trigger-Profile

This command adds the Subscriber-Sip-Trigger-Profile.

add subscriber-sip-trigger-profile sub-id=sub_1; fname=ABC; sip-trigger-profile-id=AS_1;

Service-Id

This command adds the Service ID.

add service id=ohd_vsc; fname1=ABC;

Subscriber-Service-Profile

This command adds the Subscriber-Service-Profile.

add service id=ohd_vsc; fname1=OHD; fname2=NEW; fname3;

Feature Restrictions and Limitations

The FIM/XML tool cannot be used to

???Change the interaction between internal features

???Define feature configuration properties

???Define feature support profile