|
|
This chapter describes Cisco's methods of employing a distributed model for its service provider, Voice over IP (VoIP) product suite. Although, at a certain level, each deployed device requires a unique instance of an Element Management System (EMS) to provide upstream information pertaining to fault, performance, and provisioning, it is incumbent upon the Network Management System (NMS) to appear as a virtual entity that hides the individual element complexity.
The applications and devices described in this document are positioned for service provider scale VoIP networks. Although many of the applications can be deployed in enterprises and smaller scale networks, the Cisco Internet OSS for VoIP: Infrastructure Manager (Cisco VoIP: Infrastructure Manager) Solution suite referred to in this document is aimed at the large carriers and providers of VoIP network bandwidth and services. It also concentrates on the devices deployed in a VoIP network, although non-VoIP devices integral to the VoIP network must also be taken into account.
This chapter is organized as follows:
This section describes the overall Cisco VoIP: Infrastructure Manager Solution architecture.
Figure 1-1 depicts the Cisco VoIP: Infrastructure Manager Solution architecture. The Cisco VoIP: Infrastructure Manager Solution is comprised of three functional areas:
This section describes the Cisco products used to create the Cisco VoIP: Infrastructure Manager Solution.
The following components and their respective installations and initial configurations are detailed in this document:
1. Cisco Info Center, release 3.4.1—a Service-Level Management (SLM) system that provides a consolidated view of system-wide events and status information.
2. Cisco CNS Notification Engine, release 2.0—receives Cisco IOS Syslog event messages and converts them into SNMP style var binds and forwards them to a northbound Network Management System, namely Cisco Info Center.
3. Cisco CNS Performance Engine, release 1.0—collects and receives VoIP network performance data through a variety of means including RADIUS, SNMP polling, and bulk file retrieval. This data is processed by the Cisco CNS PE application and sent northbound to a reporting application.
4. Cisco Packet Telephony Center, release 2.1—provides initial and ongoing support for configuration of Cisco VoIP networks composed of network elements such as VSC/SC2200s, H.323 gateways, and gatekeeper devices.
5. Cisco Info Center Info Mediator for the Cisco CNS Notification Engine application on the Cisco CNS Notification Engine machine (Cisco CNS probe).
6. Cisco Info Center Info Mediator for the Cisco CNS Performance Engine application on the Cisco CNS Performance Engine machine (Cisco CNS probe).
7. Cisco Info Center Info Mediator for the Cisco Element Management Framework (Cisco EMF) application on the Cisco MGC Node Manager (Cisco MNM) machine (Cisco EMF probe).
8. Cisco CNS Integration Bus—not a specific product; a technology facilitating communication between devices and applications.
This section lists the components, recommended configurations, and deployment options of Cisco Info Center in a service provider Voice over IP environment. Cisco Info Center has functionality over and above that required for VoIP networks. Extensive documentation is available for Cisco Info Center that thoroughly describes the product and it possibilities. Refer to the "Related Documentation" section in the About This Guide, for information about obtaining access to the Cisco Info Center documentation.
Cisco Info Center is a Service-Level Management (SLM) system that provides a consolidated view of system-wide events and status information. It collects event streams or messages from many different data sources and presents a single, consistent view of the current state of all Cisco Info Center managed systems. It distributes the event information to the operators and administrators responsible for monitoring service levels. This information can then be:
Cisco Info Center tracks the state of events in a high performance distributed database and presents information of interest to specific users through individually configurable filters and views. Cisco Info Center automation functions can be used to perform intelligent processing on the current state of its managed objects.
The following Cisco Info Center components are utilized in the Cisco VoIP: Infrastructure Manager Solution:
For detailed information about the Cisco Info Center components and how they interoperate, refer to Chapter 1, "Overview," in the Cisco Info Center Installation and Configuration Guide.
When you purchase Cisco Info Center, you purchase licenses for one or more Info Mediators. The Info Mediators relevant to this solution are:
This section specifies the minimum system requirements for the Cisco Info Server application. Table 1-1 contains recommendations for platform requirements in different size networks. The components of Cisco Info Center (Info Mediators) are installed on different machines with the following requirements:
| Network Size | Sun Platform | Solaris Version | Number of CPUs and Size | Swap | RAM | Hard Drive |
|---|---|---|---|---|---|---|
Small | Netra T1 | UltraSparcIIe | 1at 550 MHz | 2GB | 1GB | 2* 36GB |
Medium | Netra 20 | UltraSparcIII Sol 8 | 2 at 900 MHz | 4GB | 2GB | 2* 36GB |
Large | Netra T1405 | UltraSparcII Sol 7,8 | 4 at 440 MHz | 8GB | 4GB | 2* 36GB |
Refer to Figure 1-2 for a suggested deployment model.The illustration contains a virtual switch (an SS7 interconnect node), a virtual zone (an H.323 regional network), local event collectors, (Cisco MNM, Cisco CNS Notification Engine, and Cisco CNS PE) and a regional Event Processing Engine (Cisco Info Center). In Figure 1-2, Cisco Info Center is deployed in a redundant, fail-over model.
Cisco Info Center receives fault information from the virtual switch node through the use of the Cisco EMF probe, (a collector probe is automatically installed on the Cisco Info Center host and a sending probe is installed on the Cisco MNM/Cisco EMF machine after installing both Cisco MNM and Cisco EMF on that host). Refer to the installation and configuration information in "Fault Management."
Cisco IOS devices send Syslog events to the Cisco CNS Notification Engine which de-duplicates and pre-processes these events before converting them into SNMP style, var binds in XML format. These traps are published to the Cisco CNS Integration Bus to be picked up by the Cisco Info Center. A local Cisco CNS Performance Engine publishes threshold crossing alerts (TCA) on the Cisco CNS Integration Bus in a similar manner. These applications are installed and configured on the same host along with the corresponding Cisco Info Center Info Mediators.
Cisco IOS devices may also send SNMP v1/v2 traps to Cisco Info Center directly. The IOS devices are configured to send SNMP traps corresponding to events in addition to Syslog. SNMP traps are a subset of Syslog events, however, you may wish to send SNMP traps for redundancy. Also, the event you want covered may not yet be supported by the Syslog Collector (Cisco CNS Notification Engine). More than 25,000 Syslog events are presently supported by the Cisco CNS Notification Engine, however, for a new event or a rare event that is not supported, you may be able to configure an IOS device to support an SNMP trap, whereas incremental support for new events in Cisco CNS Notification Engine will require a software patch.
The Cisco CNS Notification Engine application is designed to relieve the Network Management System layer from the burden of interpreting and understanding the content of Cisco IOS produced Syslog error messages. In its first iteration, it becomes the collector of Syslog messages sent from Cisco IOS devices. Subsequent releases will enhance its collection functionality to include reception and processing of SNMP trap and Transaction Language 1 (TL1) messages.
Syslog messages, although adhering to a standard format, are activated with different payloads in different IOS versions and different Cisco platforms. In order to make a more consistent interpretation of IOS device generated Syslog messages, the Cisco CNS Notification Engine application was developed. The Cisco CNS Notification Engine receives Syslog messages from IOS devices, performs de-duplication and correlation and processing, and reformats them into standard SNMP-like var binds in XML, and sends them northbound to the Cisco CNS Integration Bus, to which Cisco Info Center, or other fault processing systems, subscribe. This relieves Cisco Info Center of the requirement of understanding the various formats of different Syslog messages and the need to create new processing rules in Cisco Info Center each time a new IOS version or Cisco platform is released (where many new Syslog messages are introduced).
The Cisco CNS Notification Engine also reduces the number of Syslog messages and traps that are received by Cisco Info Center. This reduction comes from de-duplication and the processing of relevant messages while discarding the unimportant messages.
When Cisco Info Center is the primary recipient of IOS Syslog messages, it has no choice but to receive and process them (including the unimportant ones). Inserting the Cisco CNS Notification Engine into the path relieves Cisco Info Center of this processing responsibility and allows Cisco Info Center to scale even higher.
Figure 1-3 illustrates the functional architecture of Cisco CNS Notification Engine. Events come into the
Cisco CNS Notification Engine through Syslog over the User Datagram Protocol (UDP). Events are processed and de-duplicated by the Cisco CNS Notification Engine. These messages are translated into standard SNMP style varbinds and published on the Cisco CNS Integration Bus, in XML format, to be picked up by the Cisco Info Center. Sequence numbers are generated with each message to guarantee delivery of the event to the Cisco Info Center.
The Cisco CNS Notification Engine application can be installed standalone or on the same host as the Cisco CNS Performance Engine application. This document details the installation and interaction of Cisco CNS Notification Engine with Cisco Info Center in a standalone (Cisco CNS Notification Engine on a dedicated machine) configuration. Cisco engineering test resources have experience with co-hosting the Cisco CNS Notification Engine and Cisco CNS Performance Engine applications on the same machine. It is recommended that deployment personnel consult with the NSITE team for tips and caveats on co-hosting these applications.
Co-hosting is an important aspect of certain smaller deployments. The only limitation to co-hosting both the Cisco CNS Performance Engine and Cisco CNS Notification Engine applications on the same machine is the amount of data to be collected and processed. Proper sizing of the Cisco CNS Notification Engine host (a Sun machine with Solaris version 8) is covered in Table 1-2) and sizing requirements for Cisco CNS Performance Engine are covered in the "Hardware Recommendations" section in "Performance Monitoring."
For networks with processing requirements within the guidelines (a machine with both applications can handle approximately one half of the input as either application installed on a dedicated machine), it is both possible and desirable (for hardware expense savings), to co-host the Cisco CNS Performance Engine and Cisco CNS Notification Engine applications on the same machine. Information about port contention and other considerations is available from the NSITE team.
In "Performance Monitoring," the Cisco CNS Performance Engine application is installed on its own host. In "Fault Management," the Cisco CNS Notification Engine is also installed on its own machine so as to follow the previously established model architecture.
The Cisco CNS Notification Engine server is a UNIX-based application that resides on a Sun server. The recommended Sun server configuration is detailed in Table 1-2.
Sizing for Cisco CNS Notification Engine is concerned with how many messages are being received from the network devices it monitors. Well behaved networks send fewer messages and traps than poorly behaved networks. Version upgrades and new device deployments will cause a flurry of messages until the network settles back into quieter state.
It is estimated that a Cisco CNS Notification Engine installation on a Sun Ultra 60 with two CPUs and 2GB of RAM can process 50 messages per second and receive 1000 messages per second. In bursting mode, the ssngBurstlog program can sustain a burst of 1000 messages per second.
In a quiet, well behaved network, a great number of devices can be supported. However, there will be times in this same network when unusual activity will cause the number of messages to spike considerably. The recommendations in Table 1-2 should be regarded as a starting point and close monitoring of any particular network can help refine the platform needs.
| Network Size | Sun Platform | Number of CPUs and Size | Swap | RAM | Hard Drive |
|---|---|---|---|---|---|
1000 to 5000 managed network elements | Sun Blade | 2 at 770MHz | 4 GB | 2GB | 2 at 31GB |
Cisco PTC provides Network Management Layer functionality and manages the network through Element Management Systems (EMSs) or through the network element's management interface (for example, SNMP or Command Line Interface (CLI)).
Cisco PTC maintains a repository of the data, consisting of customer and services information, for the managed network. This repository is used to configure the network, provision new services, and detect network layer configuration inconsistencies.
There are no extra hardware requirements for the Cisco PTC application above those called out for Cisco PTC 2.1 in "Provisioning,".
The Cisco MGC Node Manager (Cisco MNM) application is an FCAPS EMS for the PGW2200. In the area of fault management, it can display fault conditions for the PGW2200 and its attendant Signaling Link Terminators (SLTs) and gateways in its own, self- contained GUI. In conjunction with the Cisco VoIP: Infrastructure Manager Solution, it also forwards those traps to the Cisco Info Center using the Cisco Info Center Info Mediator (Cisco EMF probe).
Refer to "Provisioning," for details about Cisco MNM and Cisco EMF requirements, as well as installation and initial configuration. This document covers the installation of the Cisco EMF probe once Cisco MNM and Cisco EMF are installed.
There are no extra hardware requirements for the Cisco EMF probe above those called out for Cisco MNM 2.1 and Cisco EMF 3.2 in "Provisioning,".
Cisco Element Management Framework 3.2 (Cisco EMF) is the homogeneous Element Management Layer of the Cisco Internet Operations Support System (IOSS), building upon and adding to the Cisco EMF v3.0 and v3.1 product functionality. It comprises a highly scalable framework designed to support carrier-class Element Managers (EMs) across Cisco's service provider product lines with network event management. A range of EMSs are available with Cisco EMF v3.0, with additional EMSs available with
Cisco EMF v3.1. Cisco EMF provides common interfaces and EM services to applications in the network and service management levels of Cisco IOSS. Cisco EMF v3.2 is an update release to Cisco EMF v3.1. As well as the major feature enhancements detailed below, a large number of bug fixes and minor customer enhancements are included in this release. Consult the Cisco DDTS for full details of the bugs resolved in the Cisco EMF v3.2 release.
If you are migrating to Cisco EMF v3.2 from Cisco EMF v3.0, it is advisable first to be familiar with the Cisco EMF v3.1 feature set; Cisco EMF v3.1 included significant enhancements in fault management capability as well as northbound integration interfaces. In particular, the Cisco EMF Event Manager application, available as an option on Cisco EMF 2.1.4 but not with Cisco EMF 3.0, is now a standard part of Cisco EMF v3.1 (and above).
For more detailed information on Cisco EMF 3.2, see the documentation available from CCO at:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cemf/3_2/index.htm.
For information on the differences between Cisco EMF v3.0 and v3.1, refer to:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cemf/3_1/index.htm.
In this document, all references to Cisco EMF pertain to version 3.2.
Refer to the "Provisioning," to understand the hardware requirements and setup instructions for Cisco EMF v3.2.
The Cisco CNS Performance Engine application collects and receives VoIP network performance data through a variety of means including RADIUS, SNMP polling, and bulk file retrieval. This data is processed in Cisco CNS Performance Engine and sent northbound to a reporting application. A complete description of Cisco CNS Performance Engine and it's functionality is presented in "Performance Monitoring."
Discussions in this chapter concentrate on the installation and configuration of the Cisco CNS probe that enables communication of TCAs to Cisco Info Center over the Cisco CNS Integration Bus.
The Cisco CNS probe that is installed on the Cisco CNS Performance Engine machine does not increase the hardware requirements for the Cisco CNS Performance Engine machine. Those requirements are detailed in "Performance Monitoring."
Two possibilities exist when you activate the Cisco CNS option in the Cisco Info Center Info Mediators (probes); the Rendezvous daemon (rvd) or the Rendezvous Routing daemon (rvrd). If the devices that communicate over the Cisco CNS Integration Bus are on the same subnet, the rvd daemon suffices. If you wish to enable the Cisco CNS Integration Bus technology between devices that are not on the same subnet, you are required to activate the rvrd daemon and inform the daemon of the default gateways so the messages are properly routed.
There are no additional hardware requirements when enabling the Cisco CNS Integration Bus technology nor does it require any extra hardware devices for fault monitoring in the context of the Cisco CNS Notification Engine, Cisco CNS Performance Engine, and Cisco Info Center. It is enabled in the software and it is built into the various applications.
Posted: Thu Oct 17 03:07:56 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.