Avaya BCP - NN42020-108 - 01.04 - BCP

Nortel Multimedia Communication Server 5100
Border Control Point Fundamentals
NN42020-108
.
Document status: Standard Document version: 01.04 Document date: 27 April 2007 Copyright 2007, Nortel Networks All Rights Reserved. Sourced in Canada The information in this document is subject to change without notice. The statements, congurations, technical data, and recommendations in this document are believed to be accurate and reliable, but are presented without express or implied warranty. Users must take full responsibility for their applications of any products specied in this document. The information in this document is proprietary to Nortel Networks. Nortel, Nortel (Logo), and the Globemark are trademarks of Nortel Networks. IBM, BladeCenter, and BladeCenter T are trademarks of IBM Corporation. Motorola is a trademark of Motorola, Inc. All other trademarks are the property of their respective owners.
Revision history
April 2007
Standard 01.04. This document is up-issued to support Multimedia Communication Server 5100 Release 4.0. This document addresses CR Q01571232.
March 2007
Standard 01.03. This document is up-issued to support Multimedia Communication Server 5100 Release 4.0. This document addresses CR Q01543719.
January 2007
Standard 01.01. This document is issued to support Multimedia Communication Server 5100 Release 4.0. This document contains information previously contained in the following legacy document, now retired: RTP Media Portal Basics (NN10265-111).
January 2006
Standard 4.0. This document is up-issued to support MCS 5100 Release 3.5.
November 2005
November 2005
October 2005
Nortel Multimedia Communication Server 5100 Border Control Point Fundamentals NN42020-108 01.04 Standard Release 4.0 27 April 2007
Copyright 2007, Nortel Networks
.
4 Revision history
.
Contents
New in this release
Features 9 BladeCenter T Border Control Point 9 BCP/MAS co-residency 9 Other changes 10
How to get help

Finding the latest updates on the Nortel web site 13 Getting help from the Nortel web site 13 Getting help over the phone from a Nortel Solutions Center 13 Getting help from a specialist by using an Express Routing Code 14 Getting help through a Nortel distributor or reseller 14
13
Regulatory and license information

Red Hat Software 15 Safety information 16
15
Overview
How this chapter is organized 19 Functional overview 19 Network topologies 20 Hardware 20 Additional references 22 Software 22 BCP 7200 22 Interfaces and protocols 26
19
BladeCenter T Evolution
BladeCenter T overview 29 N+1 fault tolerance strategy 30 Conguring the BCP 7200 32 Software requirements 32 BCP 7200 management interface 33 Restrictions and limitations for the BCP 7200 33
29
BCP Installation on the IBM BladeCenter T platform

How this chapter is organized 37
.
37
6 Contents Conguration information 38 Other required information 38 Installing the BCP software 38 Beginning the BCP Installation 38 Finishing the BCP Installation 41 Next steps 42
Border Control Point 7200 VLAN tagging

Conguring VLAN tagging using the SMGUI 44 Datalling a VLAN 45 Setting VLAN Topology conguration parameters 47 Software requirements or dependencies 49 Restrictions and limitations for Border Control Point 7200 VLAN tagging 49
43
Upgrading the Border Control Point 7000 series

How this chapter is organized 51 Maintenance updates 52 How this chapter is organized 52 Functional description 52 Tools and utilities 52 Operations, administration, and management 52 Maintenance update tasks 53 Service upgrades 57 Upgrading to the BladeCenter T 68 Firmware upgrades 68 BladeServer rmware upgrade 72 BCP 7200 capacity upgrade 73 Conguration upgrades 74
51
Fault management
How this chapter is organized 75 Network fault management 75 Fault tolerance 75 BCP 7200 alarms 78 Informational and communication logs 79 System logs 83
75
Conguration management
How this chapter is organized 85 Tools and utilities 85 Run-Time Service Conguration Parameter Mapping Border Control Point 7200 conguration 88 How this chapter is organized 88 Conguring the BladeCenter T service node 88 Conguring the BladeCenter T service data 88 Static Routes Data Structure 95
.
85
86
Contents 7 Conguring the BladeCenter T 98 BladeCenter T BCP service creation 111 Stand-alone creation 111 Service Cluster Instantiation 115 Troubleshooting the IBM BladeCenter hardware 119 IBM BladeCenter hardware failure and replacement 119 BladeCenter modules 119 Blower modules 121 BladeServers (x-blade) 122 Expanding the BladeServer (x-blade-combo) 123 Replacing the SCSI drive 123 BladeCenter chassis 124
Accounting management
Functional description 125
125 127
Performance management
Viewing operational measurements 128 BCP 7200 OMs 128
Security and administration

How this chapter is organized 131 Security overview 131 BCP 7200 component-level security functions 132 User administration 133 Managing the Service Cluster 137
131
BCT conguration worksheet Appendix A Backup and recovery

How this chapter is organized 143 Prerequisites 143 Backing up the BCP 144 Error scenarios 151
139 143
Procedures
Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure 1 2 3 4 5 6 7 8 9 Beginning the BCP install process 38 Finishing the BCP installation 41 Datalling a VLAN 46 Setting VLAN Topology conguration parameters 47 Updating a software load for the BCP 7200 component 53 Shutting down the BCP 7200 component 54 Deploying the BCP 7200 component 55 Starting the BCP 7200 56 Performing an MR upgrade on an In-Service Stand-Alone BladeCenter T BCP service instance 57 Upgrading the BCP Service Cluster 61 Upgrading the Management Module rmware 68 Accessing the Nortel Application Switch 70
Procedure 10 Procedure 11 Procedure 12
.
8 Contents Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure Procedure 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 Upgrading the Nortel Application Switch rmware 71 Upgrading the BladeServer rmware 72 Obtaining alarm information 76 Clearing an alarm 77 Clearing the RTP101 Alarm (Blade out of service on initialization) 78 Clearing the RTP102 Alarm (BCP 7200 Out of Service) 78 Clearing the RTP103 Alarm (Portal Port Usage) 78 Clearing the RTP104 Alarm (Host Interface Failure) 79 Creating a static route and adding it to the BCP 7200 96 Conguring the BladeCenter T BCP 7200 99 Creating the service 113 Instantiating the service cluster 117 Removing a module 119 Installing a module 119 Replacing management modules 120 Replacing an existing ESM (I/O module) 120 Replacing power supply modules 121 Removing a blower module 121 Installing a blower module 122 Replacing an existing single-slot blade (or the processor half of a dual-slotblade) 122 Replacing the SCSI drive 123 Replacing the BladeCenter chassis 124 Setting up the remote tape drive 145 Backing up to a tape drive 146 Restoring the BCP 7200 from tape 148 Fixing an error in the installation of a USB tape drive 152
.
New in this release

This chapter describes the changes in Border Control Point Fundamentals (NN42020-108) for Multimedia Communication Server (MCS) 5100 Release 4.0.
WARNING
Do not contact Red Hat for technical support on your Nortel version of the Linux base operating system. If technical support is required for the Nortel version of the Linux base operating system, contact Nortel technical support through your regular channels.
Features
This section describes the feature impacts for this release. The features are: "BladeCenter T Border Control Point" (page 9) "BCP/MAS co-residency" (page 9) "BCP OM enhancements" (page 10)
BladeCenter T Border Control Point

MCS 5100 Release 4.0 introduces the IBM* BladeCenter* T (BCT) chassis to support the Border Control Point (BCP; formerly known as the Realtime Transport Protocol [RTP] Media Portal). Introduced in conjunction with the BCT for MAS feature, this feature uses the same hardware as the Media Application Server (MAS), and together these features work with the BCP/MAS co-residency feature. The BladeCenter T RTP Media Portal feature encompasses the introduction of the new hardware, the evolution of the BCP software to execute on the hardware, and the introduction of the N+1 (N active and 1 standby) fault tolerance strategy.
BCP/MAS co-residency
With this feature, the BCP and MAS applications can co-reside in the same IBM BladeCenter T chassis. For example, you can use the same chassis for BCP, MAS Ad Hoc Conferencing, and MAS Announcements at the same
.
10 New in this release
time. Each application runs on its own server card (known as a Blade) in the chassis. Co-residency reduces hardware costs and provides a exible growth strategy for existing systems.
BCP OM enhancements
This feature provides Operational Measurement (OM) enhancements for the BCP. These enhancements introduce new OM groups (MediaPortalInstance and Ports) and add new OM registers to the MediaPortal OM group.
Other changes
See the following sections for information about changes that are not feature-related: The BCP is enhanced to provide IEEE 802.1Q VLAN tagging functionality. VLAN tagging facilitates easier integration into the Communication Server 1000 (CS1000) solution and adds extra exibility when introducing the BCP 7200 into complex topologies. You congure and utilize IEEE 802.1Q capabilities through the System Management Console (SMC). The SMC is enhanced to enable you to specify VLAN membership for control- and media-plane points of presence. The Static Route datall is also changed to permit association of static routes to VLANs. For information about this feature, see Border Control Point 7200 VLAN tagging. Complete information about the BladeCenter T evolution is available in "BladeCenter T Evolution" (page 29). This document includes a new section called "Upgrading to the BladeCenter-T" (page 68). "Fault management" (page 75) contains new information about BladeCenter T and BCP 7200 faults and updated fault management. "Conguration management" (page 85) contains new information about run-time service conguration parameter mapping for the BladeCenter T (BCT) in a table. The section "Border Control Point 7200 conguration" (page 88) describes BCP 7200 conguration. For information about BCT troubleshooting, see "IBM BladeCenter hardware failure and replacement" (page 119). "Accounting management" (page 125) contains detailed information about changes to accounting functionality. "Performance management" (page 127) contains detailed information about performance management and a new Operational Measurement (OM) Group HALayer for the BCT.
.
Other changes
11
"Security and administration" (page 131) contains a detailed discussion of new security provided with the BladeCenter T and BCP 7200. BIOS conguration of the CPV5370 host card contains a change to step two of the procedure. This document is renumbered from NN10265-111 to NN42020-108. Unnecessary graphics are removed from this document.
.
12 New in this release
.
13
How to get help

This chapter explains how to get help for Nortel products and services.
Finding the latest updates on the Nortel web site

The content of this documentation was current at the time the product was released. To check for updates to the latest documentation for Multimedia Communication Server (MCS) 5100, go to www.nortel.com and navigate to the Technical Documentation page for MCS 5100.
Getting help from the Nortel web site

The best way to get technical support for Nortel products is from the Nortel Technical Support web site: www.nortel.com/support This site provides access to software, documentation, bulletins, and tools to address issues with Nortel products. From this site, you can: download software, documentation, and product bulletins search the Technical Support web site and the Nortel Knowledge Base for answers to technical issues arrange for automatic notication of new software and documentation for Nortel equipment open and manage technical support cases
Getting help over the phone from a Nortel Solutions Center

If you do not nd the information you require on the Nortel Technical Support Web site, and you have a Nortel support contract, you can also get help over the telephone from a Nortel Solutions Center. In North America, call 1-800-4NORTEL (1-800-466-7835). Outside North America, go to the following web site to obtain the telephone number for your region: www.nortel.com/callus
.
14 How to get help
Getting help from a specialist by using an Express Routing Code

To access some Nortel Technical Solutions Centers, you can use an Express Routing Code (ERC) to quickly route your call to a specialist in your Nortel product or service. To locate the ERC for your product or service, go to: www.nortel.com/erc
Getting help through a Nortel distributor or reseller

If you purchased a service contract for your Nortel product from a distributor or authorized reseller, contact the technical support staff for that distributor or reseller.
.
15
Regulatory and license information

This chapter contains regulatory and license information.
WARNING
Red Hat Software

Passthrough End User License Agreement This section governs the use of the Red Hat Software and any updates to the Red Hat Software, regardless of the delivery mechanism and is governed by the laws of the state of New York in the U.S.A. The Red Hat Software is a collective work under U.S. Copyright Law. Subject to the following terms, Red Hat, Inc. ("Red Hat") grants to the user ("Customer") a license to this collective work pursuant to the GNU General Public License. Red Hat Enterprise Linux (the "Red Hat Software") is a modular operating system consisting of hundreds of software components. The end user license agreement for each component is located in the components source code. With the exception of certain image les identied below, the license terms for the components permit Customer to copy, modify, and redistribute the component, in both source code and binary code forms. This agreement does not limit Customers rights under, or grant Customer rights that supersede, the license terms of any particular component. The Red Hat Software and each of its components, including the source code, documentation, appearance, structure and organization are owned by Red Hat and others and are protected under copyright and other laws. Title to the Red Hat Software and any component, or to any copy, modication, or merged portion shall remain with the aforementioned, subject to the applicable license. The "Red Hat" trademark and the "Shadowman" logo are registered trademarks of Red Hat in the U.S. and other countries. This agreement does not permit Customer to distribute the Red Hat Software using Red Hats trademarks. If Customer makes a commercial redistribution of the Red Hat Software, unless a separate agreement with Red Hat is
.
16 Regulatory and license information
executed or other permission granted, then Customer must modify any les identied as "REDHAT-LOGOS" and "anaconda-images" to remove all images containing the "Red Hat" trademark or the "Shadowman" logo. As required by U.S. law, Customer represents and warrants that it: (a) understands that the Software is subject to export controls under the U.S. Commerce Departments Export Administration Regulations ("EAR"); (b) is not located in a prohibited destination country under the EAR or U.S. sanctions regulations (currently Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria); (c) will not export, re-export, or transfer the Software to any prohibited destination, entity, or individual without the necessary export license(s) or authorizations(s) from the U.S. Government; (d) will not use or transfer the Red Hat Software for use in any sensitive nuclear, chemical or biological weapons, or missile technology end-uses unless authorized by the U.S. Government by regulation or specic license; (e) understands and agrees that if it is in the United States and exports or transfers the Software to eligible end users, it will, as required by EAR Section 740.17(e), submit semi-annual reports to the Commerce Departments Bureau of Industry & Security (BIS), which include the name and address (including country) of each transferee; and (f) understands that countries other than the United States may restrict the import, use, or export of encryption products and that it shall be solely responsible for compliance with any such import, use, or export restrictions. Red Hat may distribute third party software programs with the Red Hat Software that are not part of the Red Hat Software. These third party programs are subject to their own license terms. The license terms either accompany the programs or can be viewed at http://www.redhat.com/licenses/. If Customer does not agree to abide by the applicable license terms for such programs, then Customer may not install them. If Customer wishes to install the programs on more than one system or transfer the programs to another party, then Customer must contact the licensor of the programs. If any provision of this agreement is held to be unenforceable, that shall not affect the enforceability of the remaining provisions. Copyright 2003 Red Hat, Inc. All rights reserved. "Red Hat" and the Red Hat "Shadowman" logo are registered trademarks of Red Hat, Inc. "Linux" is a registered trademark of Linus Torvalds. All other trademarks are the property of their respective owners.
Safety information
This section contains important safety information.
.
Safety information 17
.
18 Regulatory and license information
.
19
Overview
WARNING
How this chapter is organized

This chapter is organized as follows: "Functional overview" (page 19) "Network topologies" (page 20) "Hardware" (page 20) "BCP 7200 (IBM BladeCenter T)" (page 20) "Additional references" (page 22) "Software" (page 22) "BCP 7200" (page 22) "Interfaces and protocols" (page 26)
Functional overview
The Border Control Point (BCP 7200 series) component addresses media plane-specic issues with advanced service delivery, Internet addressing efciencies, and system security. The primary function of the BCP series is to extend the reach of multimedia services so that they are accessible to obscured endpoints, devices residing behind a rewall, or a Network Address Translation (NAT) or Network Address Port Translation (NAPT) device. The BCP 7000 series also provides IP address and port pair mapping for internal and external network components as well as media anchoring and media pivot abilities. In this way, the BCP 7000 series functions as a media NAPT point that can shield network components from external exposure.
.
20 Overview
The BCP 7000 series operates under the control of a call server using the Media Portal Control Protocol (MPCP). The call server instructs the BCP when to open or close media pinholes and species which media can function. The IBM BladeCenter T (BCT) is the BCP platform for the BCP 7200 that meets the needs of a maturing Voice over Internet Protocol (VoIP) market. The BCT provides improved: density (more media ows for each unit of rack space) media bandwidth supportability reliability strategy
Network topologies
The BCP 7000 series can be deployed in a single- or dual-network conguration. For dual networks, the BCP 7000 series enables elements in the protected network to safely communicate with elements in the managed IP access network.
Hardware
The BCP 7200 is available on the IBM BladeCenter T.
Figure 1 BladeCenter T (BCP 7200)
BCP 7200 (IBM BladeCenter T)

The BladeCenter T chassis of the BCP 7200 is a rack-mounted, high-density, and high-performance blade-server system developed for Network Equipment Building Systems (NEBS) telecommunications network applications and other applications requiring additional physical robustness. The BladeCenter T unit uses BladeServers, switches, and other components that are common to the IBM BladeCenter* product line. This common component strategy makes the BladeCenter T unit ideal for applications in telecommunications networks that need high levels of computing power and access to common off-the-shelf middleware packages that are used in IT data centers.
.
Hardware
21
The BladeCenter T unit supports up to eight BladeServers, making it ideally suited for networking environments that require a large number of high-performance servers in a small space. The BladeCenter T unit provides common resources that are shared by the BladeServers, such as power, cooling, system management, network connections, backplane, and input/output (CD-ROM drive and connectors for USB, keyboard, video, mouse, and network interfaces). The following is a list of parts for the IBM BladeCenter T. For detailed information about the hardware, see http://www.ibm.com and also see the following gure, Figure 2 "IBM BladeCenter T exploded chassis" (page 21). Chassis (AC-powered chassis: Type 8730; DC-powered chassis: Type 8720) power modules (AC or DC power) media tray management modules blower modules KVM module LAN module IO modules BladeServers
Figure 2 IBM BladeCenter T exploded chassis
.
22 Overview
Additional references
For information about third-party equipment, see the following references: IBM e-server BladeCenter T Types 8720 and 8730 Installation and Users Guide IBM e-server BladeCenter T Type 8730AC Power Supply Modules IBM e-server BladeCenter T Type 8720DC Power Supply Modules IBM e-server BladeCenter HS20 Type 8843 User Guide IBM e-server BladeCenter T Management Module Installation Guide IBM BladeCenter T Management Module Users Guide Nortel Layer 2/3 GbE Switch Module for IBM e-server BladeCenter T Installation Guide
Software
CAUTION
Only Nortel-certied software may be installed on the IBM BladeCenter T. Do not install software updates obtained directly from IBM.
The BCP 7000 Series is primarily a software entity comprising logical subcomponents that participate in many planes of operation. The distribution of these logical subcomponents depends on the underlying hardware platform (BladeCenter T). This distribution affects the point of presence of the BCP in the service planes and the complexity of the implementation.
BCP 7200
The BCP 7200 consolidates all logical subcomponents onto a single piece of hardware, the BladeServer. As a result, the BCP 7200 can provide N+1 fault tolerance. The software rearchitecture required by the BladeCenter T BCP abstracts the functionality provided by the BCP from the underlying platform, establishing the BCP as a service that is independent of a xed relationship with its supporting hardware. Further, the N+1 fault tolerance framework adds another dimension to the BCP. The BladeCenter T BCP operates as either a collection of independent service instances (standalone) or as an N+1 fault-tolerant service cluster (clustered). Both standalone and clustered congurations of the BladeCenter T BCP are congured as service clusters; however, the standalone operation is congured as a 1+0 (1 active instance, and no
.
Software 23
standby instances) service cluster. The difference between the standalone and clustered congurations is their run-time characteristics and reactions to faults. When congured as a collection of standalone service instances, a single BladeCenter T can support the execution of up to eight independent nonredundant instances of the BCP Service. For more information, see Figure 3 "Stand-Alone BCP service instances (chassis view)" (page 23).
Figure 3 Stand-Alone BCP service instances (chassis view)
When congured as a redundant N+1 fault-tolerant service cluster, a single BladeCenter T supports the execution of up to seven active instances of the BCP Service and one hot standby instance that is ready to assume the active sessions for any of the active instances. For more information, see the Figure 4 "N+1 fault-tolerant BCP Service Cluster (chassis view)" (page 24).
.
24 Overview Figure 4 N+1 fault-tolerant BCP Service Cluster (chassis view)
The BladeCenter T BCP provides the abstraction of the BCP as a logical service that does not necessarily have a xed association with the underlying hardware. This layering of service and service nodes enables service instances to oat over their associated service nodes, which enables the service to survive service node (hardware) failures. This abstraction is represented in the System Management Console using the conguration entity Media Portal Cluster that is associated with underlying hardware through its relationship with the (changed) RTP Portals entity. an extension to the RTP Portals Network Element (the RTP Portals data structure includes the MPCluster name eld ) that enables service nodes (the BladeCenter T hardware represented by the network element [NE]) to be associated with the logical representation of the service (represented by the Media Portal Cluster entity). the ability to congure the BladeCenter T BCP as a standalone service instance (in other words, a 1+0 service cluster) using data structures inside the Media Portal cluster entity. the ability to congure the BladeCenter T BCP as an N+1 fault-tolerant service cluster (where N=7) using data structures inside the Media Portal Cluster entity.
.
Software 25
the ability to dene and congure static routes for the BladeCenter T BCP from the Management Console using the External Nodes, Subnet Masks, and Static Routes entities. the ability to transitively manage the BladeCenter T BCP service cluster as a set of distinct network elements. (Cluster-level management capabilities do not exist. The Cluster is managed through the coordinated management of the individual service nodes.)
Figure 5 "System Management Console: affected data structures" (page 25) shows an overview of the System Management Console that supports the BladeCenter T.
Figure 5 System Management Console: affected data structures
The major difference between the two service node variants is the location of the service-level data (see Figure 6 "Conguration data structures and relationship to service nodes" (page 26)). For the BladeCenter T, the service node is represented by the RTP Portal NE while the service data resides in the Media Portal Cluster entity. A loose coupling of service data to service
.
26 Overview
nodes is accomplished through the addition of the MPCluster name eld to the RTP Portal NE, which associates the referenced service data with the service node. In this way, the RTP Portal NEs represent the physical platform, and the BCP service becomes a logical abstraction that is dened in the Media Portal Cluster entity. This enables the BCP service instances to dynamically establish residence on the associated service nodes and to oat among the associated RTP Portal NEs as failures occur.
Figure 6 Conguration data structures and relationship to service nodes
Interfaces and protocols

While in service, the BCP communicates with other components in the system using the following protocols: MPCPMedia Portal Control Protocol controls messages between the Session Manager and the BCP. MPCP messages control the making, modication, and breaking of media session connections.
.
Interfaces and protocols
27
RTPReal-time Transport Protocol transports real-time media streams (for example, audio and video) across a packet network. RTCPReal-time Transport Control Protocol provides a means of sharing session data (for example, performance data) between endpoints. Real-time Transport Control Protocol (RTCP) provides an exchange of information pertaining to the quality of an associated media session (for example, packet counts, packets lost, latency, jitter). UDPUser Datagram Protocol transports data-based media streams (for example, le transfer). TCPTransmission Control Protocol communicates conguration, performance data, logs, and alarms (OAM data) between the BCP 7200 and the management system.
.
28 Overview
.
29
BladeCenter T Evolution
The evolution to the second generation BCP encompasses the following activities: "BladeCenter-T overview" (page 29) "N+1 fault tolerance strategy" (page 30) "Conguring the BCP 7200" (page 32) "Software requirements" (page 32) "BCP 7200 management interface" (page 33) "Restrictions and limitations for the BCP 7200" (page 33)
BladeCenter T overview
The BladeCenter T-based BCP 7200 exists in the control-plane (for MPCP messaging), the management-plane (for OAM), and the media-plane (for access to media streams). The BladeCenter T BCP 7200 appears (from a macro-level) to be the same as established legacy deployments. However, the BladeCenter T BCP 7200 does introduce some change as to how it is presented in each of the service-planes at a subatomic level (not visible to the outside world) and introduces a service-plane used for inter-cluster communications: The BladeCenter T BCP abstracts the BCP Service from the underlying service node platform. The BladeCenter T BCP 7200 consists of a BCP service, which resides in the Control-plane and the Media-Plane, and a separate BladeCenter T platform, which resides in the Management-plane. With this architectural change, the BladeCenter T BCP has separate and distinct points of presence in the Control-plane (the logical Control IP address), the Management-plane (the physical IP address of the BladeServer), and the Media-plane (the logical IP addresses associated with Net1 and Net2). The introduction of N+1 fault tolerance with the BladeCenter T BCP creates a service-plane (orthogonal to all others) to support IntraCluster Service Communications as part of the N+1 fault-tolerance framework. This service-plane is called the Peering-plane. All Service Instances that are members of the same Cluster share presence in the Peering-plane
.
30 BladeCenter T Evolution
through use of a common multicast IP address and port that uniquely identies the intracluster communication channel. By retaining presence in the service-planes and making internalized changes that are not visible to the outside world, the BladeCenter T BCP maintains functional and operational equivalence with legacy congurations from the perspective of other elements residing within the Service-planes: The BladeCenter T BCP appears identical from the perspective of the MCS Management Server as viewed in the Management-plane. This appearance is accomplished transparently as the BladeCenter T BCP continues to use the preexisting RTP Portals Network Element as its point of attachment to the Management-plane. The BladeCenter T BCP is deployed using the RTP Portals Network Element. The BladeCenter T BCP conveys telemetry (Logs, Alarms, and Operational Measurements) through the RTP Portals Network Element. The BladeCenter T BCP is managed (Start, Stop, Kill) through the RTP Portals Network Element. The BladeCenter T BCP appears identical when viewed from the perspective of the controlling Call Server (in the Control-plane) because control sessions are initiated and maintained consistently across both platforms. The BladeCenter T BCP also supports the same version of the Media Portal Control Protocol (MPCP) that is supported by legacy systems. The BladeCenter T BCP maintains support for both single- and dual-network congurations and provides the same media-layer functions as the legacy CPX8216-T systems. In this way, the BladeCenter T BCP also appears identical in terms of Media-plane capabilities.
N+1 fault tolerance strategy

The BCP 7200 reliability strategy treats the BCP 7200 as a pooled resource. Each BCP 7200 is congured to advertise its availability to provide service to a set of call servers. The call servers place each available BCP 7200 into a media resource pool that is used to serve up available media resources during call processing. In this manner, trafc is distributed over many BCP 7200s, which lessens the impact of a failure. While lessening the impact of most failure conditions, this strategy does not preserve media sessions that exist on a piece of failed hardware. As a result, failure scenarios for the original BCP 7200 can result in the loss of active calls.
.
N+1 fault tolerance strategy
31
Simplication of the software architecture affords an opportunity to take a quantum leap forward in terms of the fault tolerance attributes of the BCP 7000 series when it executes on the IBM BladeCenter T platform. The consolidation of both Host and Media Blade functions into a single entity greatly reduces the complexity of providing the N+1 fault tolerance capabilities delivered by this feature. The N+1 fault-tolerant BCP 7200 is achieved through the creation of fault-tolerant service clusters that dene a set of BCP 7200 instances (the "N" logical service instances) and that identify the target servers that host the instances ("N" servers to run the active service instances and an additional server to run a standby service instance). In this way, a fault-tolerant BCP 7200 can have active media sessions survive the catastrophic failure of a single instance of the service by having a standby instance that is ready and able to take over all media sessions that are hosted on the failed instance. The N+1 fault-tolerant capabilities of the BCP 7200 are built upon a reliable messaging framework that ensures connectivity between cluster members. The operating context of the cluster members is established through an election protocol that runs over the reliable messaging framework to dynamically determine which servers are running active instances of the BCP 7200 and which server is running the standby instance. This operating context is maintained through use of a heartbeat mechanism that continuously validates the state of members in the cluster. After the cluster is formed, all state data for each active media stream (on each active instance of the BCP 7200 in the cluster) is checkpointed to the standby BCP 7200 instance. In this way, the standby instance remains synchronized with all active instances and is thereby ready to take over processing of the sessions for any of those instances if a failure occurs. The N+1 takeover process is transparent to the endpoints that are originating and terminating the media streams relayed through the failed instance. The standby instance begins receiving and relaying those same media streams as soon as the failure is detected and takeover is affected. Initially, N+1 fault tolerance capabilities are restricted to the connes of a single IBM BladeCenter T chassis. This enables conguration of fault-tolerant clusters as small as 1+1 (1-active-instance + 1-standby-instance) and up to as large as 7+1 (7-active-instances + 1-standby-instance). See Figure 7 "BCP 7200 N+1 fault-tolerant Service Cluster (example 5 active +1 standby conguration)" (page 32).
.
32 BladeCenter T Evolution Figure 7 BCP 7200 N+1 fault-tolerant Service Cluster (example 5 active +1 standby conguration)
Conguring the BCP 7200

Hardware conguration and network connectivity occur during installation and commissioning, as well as during maintenance and repair. See the appropriate methods and procedures documentation. Component software conguration for the BCP 7200 introduces an additional layer of abstraction (MPCluster) that changes the cAfterptual view so that the BCP is now a service that oats over the associated platforms. For software conguration, see "Conguration management" (page 85).
Software requirements
The BladeCenter T BCP requires Red Hat Linux ES 3 Linux Operating System. Also, the dependency on the supporting hardware implies a dependency on the software resident in the hardware subcomponents: the
.
Restrictions and limitations for the BCP 7200
33
BladeCenter T Management Module, the Nortel Application Switch, and the BladeServer BIOS. The BCP 7200 also has rmware dependencies on maintenance diagnostics and Ethernet drivers.
Table 1 BCP 7200 external software dependencies External dependency Red Hat Linux ES 3 IBM BladeCenter T Management Module Firmware Nortel Application Switch ESM Software Image BladeServer BIOS Description the Operating System installed on the BladeServers hosting the BCP Service in the IBM BladeCenter T chassis the firmware that implements the chassis administrative functions the network switching software that provides interconnectivity to the Service Networks the BIOS resident in the BladeServer
BCP 7200 management interface

The Management Server and the System Management Console provide a graphical interface from which to congure and manage the BladeCenter T BCP. The System Management Console provides access to the following structures affected by this feature: The Network Data and Mtc data structures provide a ready means of conguring subnet extent (Subnet Masks), and static routes (External Nodes and Static Routes). The Media Portals top-level Network Elements folder contains entities associated with the BCP. The Media Portal Cluster data structure represents the logical abstraction of the BCP as a service. The MP Cluster eld introduced into the existing RTP Portal NE Instance Data (RTP Portals) enables the association of service nodes to service clusters.

The following restrictions and limitations exist on the BladeCenter T BCP: The BladeCenter T BCP does not support LiveUpdate functionality. Any conguration data changes related to data that can affect the BCP are detected and alarmed by all in-service BCPs that can potentially be impacted by the change. This alarm can be acknowledged (to mute it from the System Management Console), but the root condition persists until the aficted BCPs are cycled back into service (so that they can pick up the latest conguration data from the database).
.
BladeCenter T BCP congurations are constrained so that they can only provide service to a maximum of twenty Call Servers. This is the maximum number of Session Managers only, Gateway Controllers only, or a combination of both Session Managers and Gateway Controllers that are congured against a BCP. Due to high-layer data constraints required by the MCS solution to maintain data consistency for Media Portal Groups in the Provisioning GUI, it is not possible to change the MPCluster name associated with a RTP Portal NE. After such an association is made, the only way to alter it is to delete and readd the RTP Portal NE into the system. Each BladeCenter T service node (BladeServer) only supports two Ethernet network interface cards (NIC) that must be congured as an active/standby NIC Team. The NIC Team congured on the BladeCenter T service node (BladeServer) is not congured for Auto-Fallback and consequently, a preferred NIC does not exist. Each BladeCenter T chassis must have two Management Modules to provide fault-tolerant access to platform administration and management functions. Each BladeCenter T chassis must have two Nortel Application Switches (of the same type: copper or ber-optic) to provide fault-tolerant access to the Service Networks. The BladeCenter T BCP only supports Nortel Application Switches in IO Module Bays one and two. The Nortel Application Switch (in both copper and ber-optic variants) is the only IO Module supported for the BladeCenter T BCP. The BladeCenter T BCP is congured so that the Nortel Application Switches are only manageable through the Management Modules external interface into the Management Network (management through the Nortel Application Switch external ports is disabled in the Management Module). While it is technically possible to upgrade the Nortel Application Switch rmware through the external ports of the Nortel Application Switch, this procedure is not supported for the BladeCenter T BCP, since those external ports are not enabled for management activity. The IBM e-server BladeCenter HS20 (Type 8843L1U) BladeServer is the only supported processing element for the BladeCenter T BCP. Each BladeCenter T chassis must have four Power Modules to provide fault-tolerant power to the entire chassis. Each BladeCenter T chassis must have four Blower Modules to provide sufcient cooling for the chassis.

.
35
The BladeCenter T Stand-Alone BCP service instance is really a 1+0 (one active Service Instance, and no standby Service Instance) non-fault-tolerant Service Cluster. The 1+0 BCP Service Cluster (one active Service Instance, and one standby Service Instance) is the smallest-sized fault-tolerant conguration. The 7+1 BCP Service Cluster (seven active Service Instances, and one standby Service Instance) is the largest-sized fault-tolerant conguration. The BCP Service Cluster cannot span the BladeCenter T chassis. The fault-tolerant BCP Service Cluster can survive a single catastrophic fault at which time the Service Cluster commences operating in failure-mode and the standby Service Instance assumes the identity of the active Service Instance impacted by the catastrophe. The fault-tolerant BCP Service Cluster cannot survive subsequent catastrophic faults while operating in failure-mode (since a standby Service Instance no longer exists). The BladeCenter T BCP Service can only be managed transitively through management of the associated RTP Portal NEs. The BladeCenter T Nortel Application Switches are not congured for Auto-Fallback functionality, so a preferred Nortel Application Switch does not exist. The Static Routes data structures are applicable to the BladeCenter T BCP. The RTP Portals Network Element contains a conguration parameter MPCluster name that is used to associate the RTP Portal NE with a Media Portal Cluster. For BladeCenter T sites (both standalone and clustered), this parameter must reference a valid Media Portal Cluster data structure. The BladeCenter T BCP continues to use preexisting data structures to convey non-service specic conguration information (for example, the RTP Portals Network Element for the conveyance of engineering parameters).
.
.
37
BCP Installation on the IBM BladeCenter T platform

This chapter describes the installation of a Border Control Point on the IBM BladeCenter T Platform. The chapter is organized as follows: "Conguration information" (page 38) "Installing the BCP software" (page 38)
The RTP Media Portal on the IBM BladeCenter T (BCT) platform provides signicant capacity and robustness. Each of the eight BladeServers in the chassis is an individual Border Control Point (BCP). Each BCP can be used independently or they can be grouped into an N+1 cluster. In a cluster, one of the BladeServers acts as a hot standby and will take over if one of the remaining N BladeServers fails. The installation and conguration process must be repeated for each BladeServer in the chassis. Installation and conguration on the BCT platform involves the following steps: assembly of the hardware conguration of the BladeServer BIOS installation of the software on the BladeServer
Installing the RTP Portal software requires only a single disc. The complete base system can be installed in approximately 15 minutes or less.
.
38 BCP Installation on the IBM BladeCenter T platform
Conguration information
To congure the BCP successfully, you must capture conguration information accurately. The information that is required to provision the BCP must be collected prior to installation. For more information about collecting this data, see Table 8 "Information Required for Installation and Commissioning on the BCT platform" (page 139).
Other required information

The following information is required to fully congure a BCP: a root password for the host a password for the Nortel user a password for the sysadmin user
Installing the BCP software

Installing the BCP from a CD is a simple process. The machine is booted from CD, the information in the table is requested by the installation software, and then the software is copied to the hard drive and the machine is congured.
Beginning the BCP Installation

The BCP uses a standard RedHat Linux distribution. The following procedure describes the beginning of the BCP installation process.
Procedure 1 Beginning the BCP install process
Step 1 2
Action Establish a terminal session to the host CPU through the terminal server. The system boots from the installation CD. The initial welcome screen appears. There are no options to enter at the boot: prompt. Press Enter to begin the install.
The installation software loads and checks for existing disk partitions. You are notied of the results of the partition check, and if partitions are created and formatted, you are prompted to press Enter to proceed with the formatting. End
.
39
The next phase of the BCP installation is conguration data entry. If you are installing the BCP for the rst time, you must enter all the required data.
Conguration Data Entry

As you enter conguration data, keep in mind that a mistake can be xed. If you realize that you have entered data incorrectly, continue with the data entry process. At each major step of data entry, the installer prompts you to verify that the data is correct. If there is a mistake, answer N and reenter the data for that step. Many prompts for conguration data items have a default answer. If available, the default answer appears to the right of the prompt and is enclosed in square brackets. To accept the default value, press Enter.
First-time install
When you install the BCP for the rst time, you can enter conguration data from the system console, load a conguration le from a remote server, or restore conguration data from an existing backup. You are presented with a Conguration Data Selection screen with the following options: Manual Data Entry When you enter conguration data manually, the installer prompts you for each conguration setting. Use the information you collected in theInformation Required for Installation and Commissioning on the BCT platform table to answer the questions. Using a Remote Conguration File With this option, you can use a conguration le that is stored on a remote server. For example, if you are installing several portals, you can create a basic installation le and store it on a remote server. This le can then be used as a starting point for each portal you install. The installer prompts you to enter the IP address, gateway, and netmask for the portal you are installing. Next, you enter the remote FTP server IP address and your user name and logon information. The pathname of the directory containing the conguration le is required at this time. The pathname is relative to the home directory of the user name that you specify for the FTP logon. The installer will contact the remote FTP server and obtain a directory listing, which is displayed on the screen as follows: MCPPostInstall.log PreInstall.log BackupInfo.le lost+found portal.cfg post-install.log
.
time zones Cancel remote conguration le selection When you use the remote conguration option, choose portal.cfg (option number ve). The installer obtains the selected le and reads the conguration from that le, and then prompts you to change the conguration data. Restoring from a Prior BackupFor more information, see "Restore" (page 148).
Network Based Items

The rst phase of data conguration involves the following network-based items: Application typeA read-only value that is congured automatically by the installer and cannot be changed. It describes the type of application being installed. Platform typeA read-only value that is congured automatically by the installer and cannot be changed. This value is congured according to the hardware platform that you congure. HostnameThe name you give to the BCP. Machine Logical IPThe IP address assigned to the BCP. Default GatewayThe default gateway router assigned to the BCP host card. NetmaskThe network mask for the BCP host card. TimezoneThe timezone where the BCP is physically located. Host IP failover activeThe true or false value that controls the host IP failover service. If the service is active, the host card uses network interfaces in an active or standby conguration.
After you congure the rst phase of data conguration, the installer presents the validation screen. If the information is correct, press Enter to accept the values displayed for each item (if there are any mistakes, press N to reenter phase one data). After the items in phase one have been successfully congured, phase two of data conguration begins.
.
41
BladeServer slot and NTP clock source

The second phase of data conguration involves the following media card related information (again, each item is presented with a default value if one is available): BladeServer SlotThis is the BladeServer slot number (it must be a number between one and eight). Every BladeServer in the same chassis must have a unique slot number. NTP Clock SourceThis is the IP address of the NTP server that the RTP Media Portal obtains clock synchronization. There can be zero or more congured NTP clock sources, but only one is displayed at this time.
If the information is correct, press Enter to accept the values displayed for each item (if there are any mistakes, press N to reenter phase one data).
Finishing the BCP Installation

After you nish the second phase of data conguration, you perform the nal steps to nish the BCP installation.
Procedure 2 Finishing the BCP installation
Step 1 2
Action From the Date and Time Conguration screen, press Enter if the time is correct. Otherwise, press N to change the time. Next, the installer prompts you for the root, nortel, and sysadmin passwords. These passwords must be at least eight characters in length. The installer performs a basic validation of passwords.
The script begins installing the individual software packages. A progress indicator appears on screen. This part of the installation takes approximately 10 minutes to complete.
Next, the installer congures the system for specic BCP requirements. This step in the process takes approximately 5-10 minutes.
5 6
The system reboots. Remove the CD-ROM from the drive when it is ejected. As the system is powering on, hold down the F2 key to enter the BIOS setup. For security purposes, remove everything from the

.
boot device list except the hard drive. Save and exit the BIOS setup. The system reboots. 7 After the system reboots, press Enter to boot the default image. The logon prompt appears and the BCP is ready for software deployment. End
Next steps
When the installation is complete, the next step in deploying the Border Control Point is to congure the Media Portal using the MCS Management Console. See "Border Control Point 7200 conguration" (page 88).
.
43
Border Control Point 7200 VLAN tagging

ATTENTION
This feature only applies to the BCP 7200, which is an IBM BladeCenter T (BCT) hardware platform.
IEEE 802.1Q VLAN tagging functionality in the BCP 7200 facilitates easier integration into the CS2000 solution and adds an extra dimension of exibility when introducing the BCP 7200 into complex topologies. Virtual LANs (VLANs) are intended as a way to segment networks at Layer-2 to increase network exibility without changing the physical network topology. A side benet of this segmentation is the extra security associated with the isolation provided to each of the segments through logical separation. When a device is congured to participate in a VLAN, it becomes a member of that broadcast domain. Layer-2 segmentation is accomplished through the introduction of additional header information into the Layer-2 Ethernet Frame that associates the frame with a specic VLAN. The introduction of this additional information in the Ethernet Frame requires that network components (network interface cards) be VLAN-aware so that they can properly process such frames. The BCP 7200 platform comprises hard- and soft-subcomponents that are VLAN-aware. You can use VLAN tagging to tap into these latent abilities. Providing IEEE 802.1Q VLAN tagging support on the BCP 7200 involves the following distinct areas of work: physical interconnect of the BCP 7200 to the Service Networks. conguration of the Ethernet Switching Module (ESM) subcomponent of the BCP 7200 for proper conveyance of VLAN trafc into the Service Networks. conguration of the IEEE 802.1Q VLAN tagging capabilities in the Operating System from the MCP System Management Console (SMC).
.
44 Border Control Point 7200 VLAN tagging
enabling the IEEE 802.1Q VLAN tagging capabilities of the underlying Operating System with the BCP 7200 Media Portal Component Software.
Figure 8 BCP 7200 VLAN tagging areas of work
Conguring VLAN tagging using the SMGUI

The System Management Graphical User Interface (SMGUI) accommodates conguration of the BCP 7200 RTP Media Portal service for operation in VLAN-tagged Service Network topologies. Service Network VLAN Topology: The VLAN conguration parameter in the Network Data & Mtc folder permits specication of Service Network VLAN information. The VLAN Topology conguration parameter in the Media Portal Cluster folder permits association of an RTP Media Portal Service Instance network spaces to specic VLANs. Static Route VLAN Assignments:
.
Conguring VLAN tagging using the SMGUI 45
The Static Routes conguration parameter in the Media Portal Cluster data has a data structure that permits granular assignment of Static Routes to specic VLANs. The introduction of VLAN information into the system enables RTP Media Portal Service Instances hosted on the BCP 7200 to be congured with presence in separate VLANs that represent: a distinct network space for Control-plane trafc two separate network spaces for Media-plane trafc (one for Net1 media, and the other for Net2 media)
Figure 9 BCP 7200 SMGUI conguration of Control- and Media-plane VLANs
Datalling a VLAN
Every VLAN in the Service Network that is to be extended to the BCP 7200 must be datalled into the system. Network VLAN Topology is entered into the system using the VLAN conguration parameter in the Network Data & Mtc folder.
.
46 Border Control Point 7200 VLAN tagging Procedure 3 Datalling a VLAN
Step 1 2 3 4
Action Open the System Management Console. In the navigation pane (left-side), click the Network Data & Mtc. folder to view its contents. In the Network Data & Mtc folder, click the Media Portal Data folder to view its contents. In the Media Portal Data folder, click the VLANs conguration parameter. The VLANs conguration window appears.
In the VLANs conguration window, click the + button. The Add VLANs window appears.
6 7 8
In the VLAN Name eld, specify a unique name in the system that represents this particular data element. In the VLAN ID eld, specify the VLAN Identier (VID) that denes this VLAN in the Service Network. Click Apply. End
.
Conguring VLAN tagging using the SMGUI 47
Procedure job aid

Figure 10 SMGUI Conguration of Service Network VLANs
Setting VLAN Topology conguration parameters

After all of the required Service Network VLANs are dened in the system, you can associate them with any combination of BCP 7200 RTP Media Portal Service Instances using the VLAN Topology conguration parameters present in the Media Portal Cluster data.
Procedure 4 Setting VLAN Topology conguration parameters
Step 1 2 3 4
Action Open the System Management Console. In the navigation pane (left-side), click the Network Elements folder to view its contents. In the Network Elements folder, click the Media Portals folder and click it to view its contents. In the Media Portals folder, click the Media Portal Cluster folder to view all BCP 7200 RTP Media Portal Service Clusters datalled in the system. In the Media Portal Cluster folder, open a Media Portal Cluster instance folder to view the available conguration parameters. Locate the VLAN Topology conguration parameter.
.
Click the VLAN Topology conguration parameter. The VLAN Topology window for the current Media Portal Cluster appears in the right pane work area. In the Control VLAN eld, associate a Service Network VLAN to the Control IP address. In the Net1 Media VLAN eld, associate a Service Network VLAN to the Net1 Media IP address. In the Net2 Media VLAN eld, associate a Service Network VLAN to the Net2 Media IP address. Click Apply . Cycle the BCP 7200 (either through Stop+Start, Kill+Start, or Restart) to enable the BCP 7200 to pick up conguration changes. End
7 8 9 10 11
Procedure job aid

Figure 11 SMGUI Association of RTP Media Portal Service Instances with Service Network VLANs
.
Restrictions and limitations for Border Control Point 7200 VLAN tagging 49
Software requirements or dependencies

The following software changes are not required by this feature but occur as part of the normal course of product development: Upgrade to JVM 1.4.2_09 (moves the RTP Media Portal Component software onto the version of the Java Virtual Machine used across other product components). Upgrade to ESM rmware (up-version to collect bug-xes and to gain access to enhancements in the Layer-2 Trunk Failover mechanism that provide congurable control over the failover-trigger). Upgrade to IBM BladeCenter T (BCT) subcomponent rmware (up-version to collect bug-xes).
Restrictions and limitations for Border Control Point 7200 VLAN tagging
The following restrictions and limitations apply to BCP VLAN tagging: IEEE 802.1Q VLAN tagging support is only provided for the BCP 7200. IEEE 802.1Q VLAN tagging support is only provided for the service trafc on the BCP 7200. Tagging of the out-of-band platform management trafc (traversing the Management Modules in the chassis) is not permitted. Since VLAN tagging fundamentally changes the format of frames transmitted on a tagged port, carefully planned network designs are needed to prevent tagged frames from being transmitted to devices that do not support IEEE 802.1Q VLAN tags, or devices where tagging is not enabled. The BCP 7200 does not support live update of conguration changes, so conguration data does not get picked up in run-time until the BCP 7200 is cycled (that is, Stop + Start, Kill + Start, or Restart). Conguration parameter default values (<none>) target operation in untagged topologies. Ethernet Switching Module (ESM) restrictions and limitations with respect to IEEE 802.1Q VLAN tagging support. See the latest ESM documentation for the complete listing of restrictions and limitations, including: The ESM can support a maximum of 128 VLANs at a time. By default, the Nortel Application Switch (NAS) OS software is congured so that management ports are congured to the default VLAN 4095. The ESM can support a maximum of three separate Layer-2 Link Aggregation trunks. This limits the number of physically partitioned
.
congurations possible that support Layer-2 Fault Tolerance using Link Aggregation. All ESM ports congured as members of a Layer-2 trunk must have the same VLAN conguration. In addition: All trunk member ports must be assigned to the same VLAN conguration before the trunk can be enabled. Changes to the VLAN settings of any trunk member cannot be applied until the VLAN settings of all trunk members are similarly changed.
.
51
Upgrading the Border Control Point 7000 series

This chapter is organized as follows: "Maintenance updates" (page 52) "Upgrading to the BladeCenter-T" (page 68) "Firmware upgrades" (page 68) "Management Module rmware upgrade" (page 68) "Alteon ESM rmware upgrade" (page 70) "Blade Server rmware upgrade" (page 72)
"BCP 7200 capacity upgrade" (page 73) "Conguration upgrades" (page 74)
.
52 Upgrading the Border Control Point 7000 series
Maintenance updates
This chapter is organized as follows: "Functional description" (page 52) "Operations, administration, and management" (page 52) "Maintenance update tasks" (page 53) "Shutting down the BCP 7200 component" (page 54) "Deploying the BCP 7200 component" (page 55) "Starting the BCP 7200" (page 56)
Functional description
This chapter describes the upgrade tasks to be performed when updating a maintenance release.
Tools and utilities

Updates to the BCP 7200 are performed through the System Management Console. For more information, see the System Management Console User Guide (NN42020-110).
Operations, administration, and management

The Session Manager and Communication Server 2000 can try to contact the BCP 7200 while the update is in progress, potentially generating error logs. To eliminate this potential and minimize impact to service, shut down the BCP 7200 so that it does not accept new service requests. While shutting down, the BCP 7200 continues to process established media sessions. These preexisting media sessions are cleared as the associated calls end. The BCP 7200 automatically transitions from the active into the inactive state when active media sessions are not present. When this state transition occurs, it is safe to proceed with the update without affecting service.
CAUTION
It is possible to update and reboot one BCP 7200 in a chassis, while the BCP 7200 in the other half of the chassis continues to run the previous software. After one BCP 7200 is updated, the other BCP 7200 in the chassis can be shut down, updated, and rebooted. This rolling update only impacts available capacity and does not cause a service outage. Updating all BCP 7200s concurrently causes a service outage.
.
Maintenance updates 53
If an update fails during the initial stages, an automatic rollback to the previous load is performed. A notication of the failure appears within the System Management Console. If a component update fails after the initial stages of the update, it does not rollback automatically. A dialog box appears in the System Management Console stating that the update failed and prompts the administrator to determine whether a rollback must be performed. When the update passes, the BCP 7200 can be started again by the administrator.
Maintenance update tasks

Update operations are issued to the BCP 7200 from the System Management Console. The nal stage of update causes a reboot of all media blades. When the update operation is complete on the BCP 7200, it can be brought back into service (active) with the updated software by the administrator. To avoid any conicts with service requests from the Session Manager or Communication Server 2000, the following procedure describes the steps that must be followed when updating a software load for the BCP 7200 component.
Procedure 5 Updating a software load for the BCP 7200 component
Step 1
Action From the System Management Console, shut down the BCP 7200 component. For more information, see "Shutting down the BCP 7200 component" (page 54).
Update the software load for the BCP 7200 component. For more information, see "Deploying the BCP 7200 component" (page 55).
Start the load. For more information, see "Starting the BCP 7200" (page 56).
This procedure is complete. If applicable, return to the higher level task ow or procedure that directed you to this procedure. End
.
Shutting down the BCP 7200 component

The following procedure describes how to shut down the BCP 7200 component. To perform this procedure, the administrator must log on to the System Management Console. For detailed procedures on logging on to the System Management Console, see the System Management Console User Guide (NN42020-110).
Procedure 6 Shutting down the BCP 7200 component
Step
Action
From the System Management Console 1 2 From the System tree, Click the plus sign (+) next to Network Elements to expand the view of the folder. Next, click the plus sign next to RTP Portals to expand the view of the folder. The contents of this folder lists all BCP 7200s congured for the site. 3 4 Continue to expand the view of folders until the target BCP 7200 is selected. Click the NE Maintenance option. A window appears. 5 Select the load to update, and click the Stop button to initiate shut down.
Figure 12 BCP 7200 shutdown
The Stop button shuts down the system. The Kill button locks the BCP 7200, and the Restart button stops and starts the system. A conrmation window appears. 6 Click Yes to continue.
.
The BCP 7200 component shuts down gracefully and eventually goes into an inactive state when the last active media session ends (as in the General Information Area of the System Management Console). This procedure is complete. If applicable, return to the higher level task ow or procedure that directed you to this procedure. End
Deploying the BCP 7200 component

The following procedure describes how to update a load for the BCP 7200 component. Updates to network components must be performed in a specic order. For more information, see MCS 5100 Overview (NN42020-143).
Procedure 7 Deploying the BCP 7200 component
Step
Action
From the System Management Console 1 2 From the System tree, Click the Instance option. A window appears. Select the Server and click the Edit button. You can update the ID, server, load, and engineering elds.
Figure 13 Edit Instance variables
3 4
Click the NE Maintenance option. Highlight the RTP1 server and click the Deploy button. A window showing the progress of the update appears.

.
56 Upgrading the Border Control Point 7000 series Figure 14 Deploying the BCP 7200
Starting the BCP 7200

The following procedure lists the steps necessary to start the BCP 7200.
Procedure 8 Starting the BCP 7200
Step
Action
From the System Management Console 1 2 After the update has completed, the state changes to active. Click the Start button to cause the BCP 7200 to run the load.
Figure 15 Start the BCP 7200
.
Service upgrades
BladeCenter T BCPs do not require an upgrade.
Maintenance release upgrades

Fixes to issues reported in the BladeCenter T BCP are delivered through the existing or established MCS Maintenance Release (MR) procedure. Whenever a Maintenance Release contains xes to BladeCenter T BCP issues, the Release Notes will provide step-by-step instructions to guide the proper application of the Maintenance Release. In most cases, the BCP MR upgrade process involves shutting down the BCP (no service interruption for sites engineered with redundancy, just reduced capacity) so that the service software can be deployed, and then returning the BCP to service. The upgrade process is a straightforward procedure for standalone deployments, because there is a one-to-one mapping of service node to service instance. Managing the service node is directly analogous to managing the service. However, the MR upgrade process is more complex when applied to fault-tolerant BCP Service Clusters, since multiple Service Instances execute a common service context over a set of associated service nodes.
Procedure 9 Performing an MR upgrade on an In-Service Stand-Alone BladeCenter T BCP service instance
Step
Action
At the System Management Console, 1 Navigate to the RTP Portals Network Element representing the BladeServer participating in the 1+0 Service Cluster targeted for the MR Upgrade. Open the NE Maintenance window. Click Stop to shut down the BCP service instance on this BladeServer.
2 3
.
58 Upgrading the Border Control Point 7000 series Figure 16 Stopping the NE Maintenance
The BCP service instance on the target BladeServer advertises that it is no longer available to process sessions (MPCP RSIP message to each associated Call Server) and continues to process its preexisting sessions. After the last preexisting media session is released, the BCP becomes Inactive. 4 5 6 Navigate to the RTP Portals folder in the cong tree. Open the NE Maintenance window. Click Undeploy to remove the previous version of the service software from the BladeServer.
Figure 17 Undeploying the NE Maintenance
7 8 9 10 11
Navigate to the RTP Portals folder in the cong tree. Find the RTP Portal NE for the target BladeServer. Open the NE Instance window. Highlight the RTP Portal NE Instance. Click the -/+ (edit) button to access the NE Instance congurables.
.
Maintenance updates 59 Figure 18 Editing the NE Instance
12 13 14 15
In the Edit NE Instance window, select the load from the drop-down menu. Click Apply to commit the change. Open the NE Maintenance window for this BladeServer. Click Deploy to dispatch the service software to the BladeServer.
Figure 19 Deploying NE Maintenance
16
After the Service Instance is successfully deployed, it must be started so that instantiation of the run-time structures occurs and the service can be offered. Navigate to the RTP Portals Network Element representing the BladeServer participating in this 1+0 Service Cluster.
17 18
Open the NE Maintenance window. Click Start to start up a BCP service instance on this BladeServer.
.
60 Upgrading the Border Control Point 7000 series Figure 20 Starting NE Maintenance
As the BCP service instance on the target BladeServer begins to come into service, it retrieves its conguration data from the MCS 5100 Database Manager server. The BCP service instance determines that it is congured to participate in a Cluster, and then locates the specic Cluster conguration (Media Portal Cluster data). Instantiation of the service proceeds using the Media Portal Cluster Data to congure the BCP Service in run-time. Some of the rst processes started by the BCP service instance are those that support the N+1 fault-tolerant framework. In other words, they allocate the congured multicast address and port, start the reliable messaging framework to open the intracluster communications channel. As the N+1 fault-tolerant framework processes come up, they establish the Cluster in run-time. Since this is the rst BCP service instance in the Cluster, it is determined to be an active instance; in fact, since this is congured as a 1+0 Stand-Alone this is the only instance of the service. After the BCP service instance is congured as active, it issues MPCP RSIP messages to all of its congured Call Controllers (the Session Managers and the Gateway Controllers as congured in the Media Portal Cluster Data) to advertise its ability to provide service. After this point the BCP service instance can be called upon to service calls. End
BCP Service Cluster MR upgrade

The following activities are performed in the course of applying a Maintenance Release upgrade to a BCP Service Cluster.
.
Maintenance updates 61 Procedure 10 Upgrading the BCP Service Cluster
Step
Action
At the System Management Console, 1 Remove the active BCP service instances from service as follows for each BladeServer hosting an active Service Instance.
Figure 21 BladeCenter T BCP Service Cluster MR Upgrade (1 of 4)
Shut down the BladeServer hosting the active BCP Instance using the following steps. Navigate to the RTP Portals Network Element representing the BladeServer that is hosting the active BCP service instance for the Service Cluster targeted for the MR upgrade.
3 4
Open the NE Maintenance window. Click Stop to shut down the active BCP service instance on this BladeServer.
.
62 Upgrading the Border Control Point 7000 series Figure 22 Stopping NE Maintenance
The BCP service instance on the target BladeServer advertises that it is no longer available to process new sessions (MPCP RSIP message to each associated Call Server), and continues to process its preexisting sessions. The standby BCP service instance remains in service and ready to take over in the event that the active Service Instance encounters a failure condition. 5 After the last preexisting media session is released, the target BCP becomes Inactive. For larger-sized Service Clusters, repeat this shutdown procedure for each BladeServer associated with an active BCP service instance prior to taking the standby Service Instance out of service. Remove the Standby BCP from service. Shut down the standby BCP service instance using the following steps. Navigate to the RTP Portals Network Element representing the BladeServer that is hosting the active BCP service instance for the Service Cluster targeted for the MR upgrade.
.
Maintenance updates 63 Figure 23 BladeCenter T BCP Service Cluster MR Upgrade (2 of 4)
7 8
Open the NE Maintenance window. Click Stop to shut down the active BCP service instance on this BladeServer. The standby BCP service instance becomes Inactive.
Undeploy the Service Software from the hosting BladeServers using the following steps.
.
64 Upgrading the Border Control Point 7000 series Figure 24 BladeCenter T BCP Service Cluster Deploy (3 of 4)
Navigate to the RTP Portals folder in the cong tree.

Figure 25 Navigating to the RTP Portals folder
10 11 12 13
Open the NE Maintenance window. Click Undeploy to remove the previous version of the service software from the BladeServer. Similarly, repeat this procedure for each BladeServer associated with this Service Cluster. Deploy the service software to all BladeServers associated with this Service Cluster using the following steps.
.
14 15
Navigate to the RTP Portals folder in the cong tree and nd the RTP Portal NE for the target BladeServer Open the NE Instance window, highlight the RTP Portal NE Instance, and click the -/+ (edit) button to access the NE Instance congurables.
Figure 26 Editing the Instance
16 17 18
In the Edit NE Instance window, select the Load from the drop-down menu and click Apply to commit the change. Open the NE Maintenance window for this BladeServer. Click Deploy to dispatch the service software to the BladeServer.
Figure 27 Deploying
19 20
Repeat this process to deploy service software to every BladeServer associated with this Service Cluster. After the Service Cluster is successfully deployed, it is brought into service (transitively) as each of the associated BladeServers is started. In this way the member Service Instances are started individually so that instantiation of the run-time structures occurs, the Cluster forms, and service can be offered. Startup of individual
.
Service Instances can occur anytime after the service software is deployed to the BladeServers participating in the Cluster. This process is repeated for each of the RTP Portal NEs representing a member of the Cluster. Navigate to the RTP Portals Network Element representing a BladeServer participating in this 1+0 Service Cluster.
Figure 28 BladeCenter T BCP Service Cluster Deploy (4 of 4)
21 22
Open the NE Maintenance window. Click Start to start up a BCP service instance on this BladeServer. Issuing the Start command to the RTP Portal NE representing the other RTP Portal NE associated with this 1+0 Fault-Tolerant Service Cluster occurs in a similar fashion. As the BCP service instance on the target BladeServer begins to come into service, it retrieves its conguration data from the MCS 5100 Database Manager. The BCP service instance determines that it is congured to participate in a Cluster, and then locates the specic Media Portal Cluster data. Instantiation proceeds using the Media Portal Cluster data to congure the service. The other BCP service instance starts up in a similar fashion. Some of the rst processes started by the BCP service instance are those that support the N+1 Fault-Tolerant Framework (for example, they allocate the congured multicast address and port and start the reliable messaging framework to open the intracluster

.
communications channel). Since this is the rst BCP service instance in the 1+0 Cluster, it is determined by the N+1 Fault-Tolerant Framework to be an active instance. As the second BCP Instance starts up and joins the Cluster, the N+1 Fault-Tolerant Framework determines that, since this is congured as a 1+0 Cluster, this instance must be the Standby. This second BCP Instance operates in Standby mode, checkpointing all service data from the active Service Instance and monitoring its status and waiting for the opportunity to assume activity in the event that the active Service Instance encounters a fault. When a BCP service instance is congured as active, it issues MPCP RSIP messages to all of its congured Call Controllers (Session Managers and Gateway Controllers as congured in the Media Portal Cluster data) to advertise its ability to provide service. After this point, the Cluster has come into service and the active BCP service instance is called upon to service calls. In the course of processing service requests, all active BCP service instances communicate inside the Cluster to checkpoint service data to the Standby Service Instance and convey status so that the Cluster remains synchronized and able to survive the failure of one of its members. 23 This procedure is complete. If applicable, return to the higher level task ow or procedure that directed you to this procedure. End
.
Upgrading to the BladeCenter T

The introduction of the BladeCenter T BCP brings with it a number of upgrade considerations that span from the underlying platform (for example, BladeCenter T chassis subcomponents: Management Module rmware, Nortel Application Switch rmware, BladeServer rmware, as well as the introduction of additional hardware to support growth in demand for the service) to the BCP service (in other words, service-level software release upgrades, maintenance release upgrades, conguration upgrades). These areas are described in more detail in the following sections.
ATTENTION
For a redundant System Manager only, following the upgrade of the BCP, return to the System Manager upgrade procedure at the step "Deploying and starting the Network Elements."
Firmware upgrades
This section describes how to upgrade various rmware.
IBM Management Module rmware upgrade

This procedure must be executed only if the Management Module rmware is determined to be out of compliance with the approved rmware list. Firmware must be current as of the time the system leaves the conguration facility. Subsequent rmware updates are provided through normal support channels when deemed necessary.
Procedure 11 Upgrading the Management Module rmware
Step
Action
At the Management Module web interface, 1 Log on to the Management Module web interface.
.
Upgrading to the BladeCenter T Figure 29 Logging on to the Management Module
69
2 3 4
From the MM Control menu, Click Firmware Update. Click Browse to locate the rmware le to be used for the upgrade. Click the desired .PKT le and select Open. The le (including the full path) must appear in the box beside the Browse button. Five packet les can be updated: CNETBRUS.PKT, CNETMNUS.PKT, CNETRGUS.PKT, REMOTEKM.PKT, and DUALPS2.PKT.
Click Update to begin the update process. A progress indicator is displayed as the le is transferred to temporary storage on the Management Module. Remain on this page until the transfer is complete, at which point a conrmation page will appear.
6 7
Verify that the le type shown on the Conrm Firmware Update page is what you intended to update. If not, click Cancel. Click Continue to complete the update process. A progress indicator is displayed as the rmware update progresses. Remain on this page until the update process is complete, at which point a status page will appear to indicate whether the update is successful. Additional instructions will appear on this page if necessary.
8 9
Repeat the preceding steps for each packet to be updated. Restart the Management Module. This will not affect the BladeServer power status.

.
From the MM Control menu, click Restart MM. 10 11 Click Restart. Click OK to conrm that you want to restart the management module. The management module will restart. The current connection to the management module is lost. You will need to reconnect to the management module web interface using the congured IP address for the external interface, if changed. End
Nortel Application Switch rmware upgrade

This procedure must be executed only if the Nortel Application Switch rmware is determined to be out of compliance with the approved rmware version. Firmware must be current as of the time the system leaves the conguration facility. Subsequent rmware updates are provided through normal support channels when deemed necessary. The Nortel Application Switch uses two rmware images: an OS image and a Boot image. Firmware is transported to the Nortel Application Switch using FTP/TFTP from a remote FTP/TFTP server that is reachable through the external ports on the Management Module. To update the rmware for the Nortel Application Switch, from the command line, use the following procedures. The following steps reect the use of a TFTP server. A FTP server can also be used.
Procedure 12 Accessing the Nortel Application Switch
Step
Action
At the web browser, 1 Using Web-based access as an example, the following procedure can be followed to log on to the Nortel Application Switch as an administrator and so to access operational, administrative, and maintenance functions: Access the Nortel Application Switch (for example, by using its IP Address) through a Web-browser on the Managed Network. Prior to permitting access, the Nortel Application Switch will prompt for a User Name and Password to authenticate the access request. The User ID and Password elds are case-sensitive. To maintain system security, change the password after you log on for the rst time.
.
Upgrading to the BladeCenter T
71
After the user is authenticated, the Nortel Application Switch permits access and displays the main administrative web-page from which all administrative functions can be run. End
Procedure 13 Upgrading the Nortel Application Switch rmware
Step 1 2
Action Download the Nortel Application Switch software package (zip le) to the machine where the TFTP server resides. Extract the Boot and OS image les into a directory. Enable the server and congure its default directory to the one where the image les reside. Download the Nortel Application Switch software package (zip le) to the machine where the TFTP server resides (step 1). Access the Nortel Application Switch command line. Navigate from the main menu to the System -> Cong/Image Control level. The Nortel Application Switch provides storage for two OS images and one Boot image. Load the OS image into one of the image banks.
3 4 5 6
7 8 9
Reset the switch. Load the Boot image. Reset the switch. When you reset the switch, it boots using the selected image (1 or 2). Ensure that you are booting from the upgraded image (see the Next Boot Image Selection eld).
10
Upgrade the OS image by entering:

/boot/gtimg X TADDR 1.0.1.6_OS.img
where X => 1 or 2 (depends which image bank you want to use) TADDR => IP Address of the TFTP Server
.
Nortel recommends that you retain the previous OS version by loading the upgrade into the other image bank and resetting the switch using the new image. (Use the /boot/image command to select the preferred image.) 11 12 Answer Y to the conrmation question and then wait for the upgrade to complete successfully. Enter: /boot/reset You must reset the switch to activate the new image. Resetting the switch logs you out of the CLI, so steps 4 and 5 need to be executed again before proceeding to the next step. A switch reset is completed in approximately 60 seconds. 13 Upgrade the boot image by entering:
/boot/gtimg boot TADDR 1.0.1.6_Boot.img
14 15
Answer Y to the conrmation question and then wait for the upgrade to complete successfully. Enter: /boot/reset For more information, see the Nortel Layer2/3 GbE Switch Module for IBM e-server BladeCenter T Installation Guide. End
BladeServer rmware upgrade

This procedure must be executed only if the BladeServer rmware is determined to be out of compliance with the approved rmware version. Firmware must be current as of the time the system leaves the conguration facility. Subsequent rmware updates are provided through normal support channels when deemed necessary.
Procedure 14 Upgrading the BladeServer rmware
Step
Action
At the Management Modules web interface, 1 2 Log on to the Management Module web interface. From the Blade Tasks menu, click Firmware Update.
.
Upgrading to the BladeCenter T Figure 30 Firmware update
73
3 4 5 6
From the Upgrade Blade Firmware screen, select the target BladeServer from the target drop-down menu. In the Firmware le eld, click Browse. From the resulting File Upload dialog box, select the rmware le to be used for the upgrade, and then click Open. Click Update. For further details, see the IBM BladeCenter Management Module Users Guide. End
BCP 7200 capacity upgrade

As the demand for service grows, it is possible to grow the installed base of BCPs through the introduction of a BladeCenter T chassis or the addition of BladeServers into an existing BladeCenter T chassis (to supply service nodes on which new BCP service instances can run). The addition of hardware (chassis or BladeServers in existing chassis) is easily accomplished using the appropriate installation and commissioning procedure to properly position the hardware to host the Service Instances. For cases where capacity is expanded by adding BladeServers to an existing chassis, the BladeServers can be inserted and fully installed and commissioned without impact to the Service Instances running on the other BladeServers in the chassis. However, actually establishing an actively running BCP service instance on the BladeServer requires associated conguration datall (specically, Service Instances in the Media Portal Cluster data structure, and RTP Portal NEs in the RTP Portals entity).
.
The simplest way to increase capacity, without impacting service, is through the introduction of BCP Service Clusters (either 1+0 standalone or N+1 Fault-Tolerant) on hardware, as this entails the straightforward addition of unit-capacity into the system without having to coordinate with the existing installed base. Expanding the capacity of existing N+1 Fault-Tolerant Clusters is more complex. This complexity stems from the need to update the conguration for an in-service topology (in other words, changes to the Media Portal Cluster entity for an operational Service Cluster) and to coordinate the delivery of this Service Cluster conguration to service nodes associated with the Service Cluster. Since the BCP does not support LiveUpdate (the ability to consume conguration data changes on the y) it is necessary to cycle the whole BCP Service Cluster out of service and back into service to pick up conguration changes. Unfortunately, while the BCP is out of service, the service capacity of the system is temporarily reduced.
Conguration upgrades
The BladeCenter T BCP variant does not support the ability to consume conguration data changes on-the-y (LiveUpdate). As a consequence, it is necessary to cycle the whole BCP out of service and back into service to pick up conguration changes. Unfortunately, while the BCP is out of service, the service capacity of the system is temporarily reduced. With respect to conguration upgrades for the 1+0 standalone BladeCenter T BCP Service Cluster, the single RTP MediaPortal NE is shut down (Stop command) and quickly restarted (Start command) so that the conguration data is picked up. This procedure is similar to that used to apply MR Upgrades to the standalone BCP except that there is no need to Undeploy and Deploy the service software. Conguration changes to existing N+1 Fault-Tolerant Clusters are more complex because the entire Service Cluster must be cycled out of service and back into service so that there is run-time synchronization of the conguration data and so that all Service Instances run with the same service context. The extent of the impact of the temporary decrease in capacity accompanying this action can be large (as is the case for a 7+1 fault-tolerant BCP Service Cluster). The actual procedure used to apply conguration changes to a BCP Service Cluster is similar to that used to apply MR Upgrades to a BCP Service Cluster except that there is no need to Undeploy or "Deploy" the service software.
.
75
Fault management
This chapter is organized as follows: "Fault tolerance" (page 75) "Fault management procedures" (page 76) "BCP 7200 alarms" (page 78) "Informational and communication logs" (page 79) "System logs" (page 83)
Network fault management

The system handles network fault management through the reporting of alarms and logs to the Fault Performance Manager. You can view BCP 7200 alarms and logs from the System Management Console. For further details related to alarms, see the Alarm and Log Reference (NN42020-703).
Fault tolerance
The BCP 7200 provides base capabilities that signicantly improve the performance and reliability of the system if a fault occurs. These capabilities include: Dynamic Pool Registration provides a basic mechanism that ensures resource availability and utilization in the event of loss of communications with a call server. Dynamic Pool Registration provides this mechanism through generation of periodic registration messages (over the control channel) to each of the call servers congured for the BCP 7200. This function works in tandem with call server redundancy to ensure that BCP 7200 resources continue if a call server fails. The BCP 7200 is congured to advertise its availability with the standby call server. This conguration enables the standby server to immediately begin using the BCP 7200 for session requests whenever a failure condition occurs on the active call server.
.
76 Fault management
Idle Session Detection enables the BCP 7200 to detect and recover media resources associated with idle media sessions. This basic capability enables the system to recover resources as well as maintain capacity and performance. Media Survivability enables the BCP 7200 to permit media sessions to survive (through to session completion) in the absence of control signaling from the call server. This capability enables the system to permit media sessions to continue through to completion in the wake of loss of communications with the call server. Host IP Failover provides redundant (active/standby) network connectivity for the BCP 7200 host card so that if a network issue affects one of the connections, the other connection assumes activity. This functionality enables the BCP 7200 to maintain control and OAM connectivity if a network fails. Shared Resource enables the distribution of BCP 7200 resources through association with multiple call servers. The strategy of distributing media sessions over multiple BCP 7200s strengthens the network ability to continue processing sessions if a condition fails. Failures result in diminished capacity, but not necessarily a service outage, since many other BCP 7200s remain available for the call server to use. Host CPU Recovery provides for media stream survival through a host CPU failure and subsequent recovery. After host CPU failure, media streams on subtending media blades continue to ow undisturbed. During the subsequent host CPU recovery process, communications are reestablished with the media blades, and available capacity information is retrieved from each of the media blades. After the BCP 7200 resumes service, it offers the remaining available capacity on the media blades for processing sessions.
Fault management procedures

This section describes how to obtain alarm information and clear alarms.
Alarm surveillance
The following procedure lists steps to obtain information regarding alarms.
Procedure 15 Obtaining alarm information
Step
Action
From the System Management Console 1 On the Alarm Bar, right-click and select Logical View. A window appears.
.
77
2 3
Open the RTP Portal folder by clicking on the plus sign. Highlight the target. At the bottom of the Logical ViewsLogical Views screen, click the Alarm Browser button.
Figure 31 Alarm Browser
Select an alarm to view alarm details. For alarm severity classication, see the Alarm and Log Reference (NN42020-703). End
Clearing an alarm
The following procedure lists steps to clear an alarm.
Procedure 16 Clearing an alarm
Step
Action
From the System Management Console 1 From the Alarm Browserwindow, click the alarm row. Information regarding the alarm appears in the information screen at the bottom of the window. 2 Click the Clear button.
.
78 Fault management
End
BCP 7200 alarms

This section describes how to clear certain alarms that affect the BCP 7200. For more information about BCP 7200 alarms, see Alarm and Log Reference (NN42020-703).
Procedure 17 Clearing the RTP101 Alarm (Blade out of service on initialization)
Step 1
Action Ensure network connectivity between the host and blade, or network connectivity on its other interfaces (link LED is lit on the blade card). Verify that the media blade is running (Telnet to the suspect media blade). Contact your next level of support with the results of these tests. End
Procedure 18 Clearing the RTP102 Alarm (BCP 7200 Out of Service)
Step 1 2
Action Ensure network connectivity between the host and blade, or network connectivity on its other interfaces (link LED is lit on the blade card). Contact your next level of support. End
Procedure 19 Clearing the RTP103 Alarm (Portal Port Usage)
Step 1
Action Ensure the congured capacity limits (the ports conguration parameter) provide adequate capacity to handle session load. This alarm is cleared after occupancy falls following the congured onset threshold. Contact your next level of support.
.
79
End
Procedure 20 Clearing the RTP104 Alarm (Host Interface Failure)
Step 1 2
Action Ensure network connectivity. Verify that interfaces have a good connection to the network (link LED is lit on the host card). Ensure that IP failover functionality is enabled on the BCP 7200. Verify that the host IP failover settings are properly congured during installation and commissioning. Verication and conguration of settings is performed using the PortalConf.pl script on the Host. This alarm is cleared after both host Network Interfaces do not exhibit any communications problems. If the alarm persists, contact your next level of support. End
Additionally, alarms are generated whenever the Session Manager does not receive responses to requests to the BCP 7200. RTP108 and RTP 109 are generated by the Session Manager to indicate that the connection with the BCP 7200 is lost. For information regarding these alarms, see the Alarm and Log Reference (NN42020-703).
Informational and communication logs

Logs assist with the maintenance and operation of the BCP 7200. Information logs begin with the number 9 (RTP906), where communication logs begin with 1 (RTP108). Administrative logs begin with the number 8 (RTP801). Host Recovery-Mode Initiated, RTP906. Produced upon recovery of the BCP 7200 Host application upon discovery of preexisting media sessions. No action is required. Host Recovery- Mode Completed, RTP907. Produced during the Host CPU recovery process to report the number of connections recovered on a media blade. No action is required. Lost connection with BCP 7200, RTP108. Ensure the referenced BCP 7200 is accessible over the network, and functional. If it is not functional, restart the BCP 7200.
.
80 Fault management
Blade Recovery-Mode Initiated, RTP909. Indicates that the Host CPU was able to reestablish communication with a subtending media blade and that the media blade is supporting connections. No action is required. Blade Recovery-Mode Completed, RTP910. Indicates the Host CPU was able to reestablish communication with a subtending media blade and reports the number of connections over which the Host CPU is able to restore control. No action is required. Connection Map Increase Capacity, RTP911. Generated whenever it is necessary for an increase in the size of the Hash Map used to store connection information. This can indicate a need for additional BCP 7200 resources. Connection Map Increase Capacity Denied, RTP912. Generated whenever a request for an increase in the size of the Hash Map is denied. This indicates the Hash Map is already double in size, and prevents unbounded increases in the size of the Connection Map. Report this log to your next level of support. Connection Map Increase Capacity Failed, RTP913. Generated whenever a request for an increase in the size of the Hash Map fails due to some unforeseen software issue. Report this log to your next level of support. Connection Not Found, RTP914. Generated whenever an audit is performed over the Connection Map, and a particular connection is not found on the corresponding media blade to match the entry in the Connection Map. No action is required. Connection Idle, RTP915. Generated whenever an audit is performed over the Connection Map, and a particular connection is found idle on the corresponding media blade. No action is required. Connection Exceeds Long Idle Duration, RTP916. Generated whenever an audit is performed over the Connection Map, and a particular connection is found on the corresponding media blade that exceeds the Long Idle Duration threshold. No action is required. Connection Exceeds Long Call Duration, RTP917. Generated whenever an audit is performed over the Connection Map, and a particular connection is found on the corresponding media blade that exceeds the Long Call Duration threshold. No action is required. Failed to Send Signal, RTP118. Generated whenever an attempt to dispatch an outgoing signal fails. No action is required. Failed to Reboot IO Exception, RTP919. Generated whenever a request for reboot of the system fails due to a software request for this reboot. Report this log to your next level of support.
.
81
No Blades Congured, RTP920. Generated whenever the BCP 7200 initiates in a state in which no media blade information is congured from the System Management Console. Install the media blade to activate the BCP 7200. Unknown Proxy, RTP921. Generated whenever a request for service is made from an unknown proxy, one which is not datalled for this BCP 7200. Investigate the source proxy to ensure that it is a valid network node, and if it must be part of the BCP 7200 datall. Unable to Register with Proxy, RTP922. Generated whenever an attempt to send a registration message to a proxy fails. Host Interface Status File Problem, RTP923. Generated during a failed attempt to establish a le handle for the interface status le, read from the le handle, or the handle does not exist. Verify that the host IP failover setting is properly congured from the System Management Console. Report this log to your next level of support. Lost connection with Last BCP 7200, RTP105. Ensure the referenced BCP 7200 is functional. If not, the user is required to restart the BCP 7200. Blade out of Service for Network Difculty, RTP106. Ensure network connectivity between the host and blade, or network connectivity on its other interfaces (link LED is lit on the blade card). Blade out of Service for Public Network Difculty, RTP107. Ensure network connectivity between the host and blade, or network connectivity on its other interfaces (link LED is lit on media blade, ping the media blade). Lost connection with BCP 7200, RTP109. Ensure the referenced BCP 7200 is accessible over the network and functional. If it is not functional, restart the BCP 7200. BCP 7200 does not support live conguration update, RTP801. Conguration data change does not take effect until the BCP 7200 is reinitialized using the Stop/Start, Restart, or Kill/Start maintenance commands. Stop and then start the Portal so that it picks up the conguration change. System Property Portal.Cong.BRHOME is not dened, RTP802. The Portal.Cong.BRHOME is not dened. Contact your next level of support. Portal Out of Service because invalid number of Call Servers Datalled, RTP803. Portal Out of Service because invalid number of Call Servers are datalled for a BCP 7200. Three Call Servers are datalled against an RTP instance that supports a maximum of two. Ensure a valid number of Call Servers are datalled for a BCP 7200.
.
82 Fault management
Host Recovery-Mode Initiated, RTP110. Produced during recovery of the BCP 7200 Host application after discovery of preexisting media sessions on a media blade. No action is required. Blade Recovery-Mode Completed, RTP111. Indicates that the host can establish communication with a subtending media blade. This log also reports the number of connections over which the Host was able to restore control. No action is required. Host Recovery-Mode Initiated, RTP112. Produced at the start of the BCP 7200 host application recovery process. This process attempts to reconstitute control over all preexisting media sessions. No action is required. Host Recovery - Mode Completed, RTP113. Produced during the host recovery process to report the number of connections recovered on a specic media blade. No action is required. Host Recovery - Mode Blade Communication Failure, RTP114. Produced during the host recovery process to report the number of media blades with which the Host failed to establish communications. No action is required. No Blades Congured, FTP200. Generated whenever the BCP 7200 initializes in a state in which media blade information is not congured. The BCP 7200 requires at least one media blade to provide service. Install a media blade and congure it from the System Management Console to successfully activate the BCP 7200. Failed to Reboot IO Exception, RTP201. Generated whenever a request for reboot of the BCP 7200 fails due to a software exception. Report this log to your next level of support. Unknown Proxy, RTP202. Generated whenever a request for service is made from an unknown proxy, one which is not congured for the BCP 7200. Investigate the source proxy to ensure that it is a valid network node. Either update the conguration to include the node or secure the control plane. Unable to Register, RTP203. Generated whenever an attempt to send a registration message to one of the congured proxies fails. Verify that the conguration data represents an existing proxy. Verify that the affected proxy exists and is reachable in the network. Connection Not Found, RTP204. Generated whenever an audit is performed over the Connection Map, and a particular connection is not found on the corresponding media blade. Report this log to your next level of support. Connection Idle, RTP205. Generated whenever an audit is performed over the Connection Map, and a particular connection is unexpectedly
.
83
found idle on the corresponding media blade. The invalid idle connection is identied in this log. No action is required. Connection Exceeds Long Idle Duration, RTP206. Generated whenever an audit is performed over the Connection Map, and a particular connection is found on the corresponding media blade which exceeds the Long Idle Duration threshold. No action is required, unless this log is generated excessively, in which case, the Long Idle Duration period can be congured for a longer interval. Connection Exceeds Long Call Duration, RTP207. Generated whenever an audit is performed over the Connection Map, and a particular connection is found on the corresponding media blade which exceeds the Long Call Duration threshold. No action is required. Host Interface Status File Problem, RTP208. Generated during a failed attempt to access the interface status le. Verify the host IP failover settings are properly congured using the PortalCong.pl script on the Host. Report this log to your next level of support. Connection Map Increase Capacity, RTP300. Generated whenever it is necessary for the BCP 7200 to autonomously increase in the size of the Hash Map used to store connection information. This can indicate a need for additional BCP 7200 resources. Report this log to your next level of support. Connection Map Increase Capacity Denied, RTP301. Generated whenever a request for an increase in the size of the Hash Map is denied. This log indicates that the Hash Map is already increased in size and prevents unbounded increases in the size of the Connection Map. Report this log to your next level of support. Connection May Increase Capacity Failed, RTP302. Generated whenever a request for an increase in the size of the Hash Map fails due to some unforeseen software issue. Report this log to your next level of support.
System logs
System logs are discussed in detail in the Alarm and Log Reference (NN42020-703).
.
84 Fault management
.
85
Conguration management
This chapter includes information regarding the reconguration and maintenance of the BCP 7200. It assumes that the BCP 7200 is installed and properly deployed. For more information about installation, see Border Control Point commissioning procedures The chapter is organized as follows: "Tools and utilities" (page 85) "Run-Time Service Conguration Parameter Mapping" (page 86) "Border Control Point 7200 conguration" (page 88) "Conguring the BladeCenter-T service node" (page 88) "Conguring the BladeCenter-T service data" (page 88) "Conguring the BladeCenter-T" (page 98) "Stand-alone instantiation" (page 111) "Service Cluster Instantiation" (page 115) "Run-Time Service Conguration Parameter Mapping" (page 86)
Tools and utilities

You deploy and congure the BCP at the System Management Console and the Provisioning Client. For more information, see System Management Console User Guide (NN42020-110), and the Provisioning Client User Guide (NN42020-105). Administrators can initially deploy and congure the BCP component using the Add operation on the System Management Console. The query operation is used for viewing conguration property values. The modify operation is used for changing the values of conguration properties anytime after initial deployment.
.
86 Conguration management
Conguration changes do not occur in real-time. Rather, they are persistently stored in the Management Database Server until the BCP is restarted.
Run-Time Service Conguration Parameter Mapping

Table 2 "Service conguration parameters for the BladeCenter T" (page 86) maps and compares the location of service conguration parameters for the BladeCenter T service nodes.
Table 2 Service conguration parameters for the BladeCenter T BladeCenter T Parameter Server (OAM-only IPaddr) Data Structure Network Elements -> Media Portals -> RTP Portals -> Instance (RTP Portals Network Element) Service ID Control IPAddr SubnetMask Net1 Media IPAddr SubnetMask Net2 Media IPAddr SubnetMask Control IPAddr Net1 Media IPAddr Net2 Media IPAddr Number of Port Min Port Value Max Port Value Network Elements -> Media Portals -> Media Portal Cluster ->Configuration Parameters (BCP Service Cluster Data) Network Elements -> Media Portals -> RTP Portals -> Service Instances (BCP Service Cluster Data)
.
Run-Time Service Conguration Parameter Mapping 87
BladeCenter T Parameter Call Legs Critical PortUsage Alarm Level Major PortUsage Alarm Level Minor PortUsage Alarm Level Long Call Duration Long Idle Duration Idle Session Audit Period Poll Timer Delay Multicast IP Mutlicast Port HeartBeat Interval Standalone Refers to -> Network Data and Mtc ->Static Routes Session Manager Network Elements -> Media Portals -> Media Portal Cluster ->Fault Tolerance (RTP Portals Network Element) -> Media Portal Cluster ->Static Routes (RTP Portals Network Element) Network Elements -> "Media Portals -> Media Portal Cluster ->Session Managers (RTP Portals Network Element) Data Structure
Discovery Probe Timer Period Gateway Controller Discovery Probe Timer Period Network Elements ->Media Portals ->Media Portal Cluster ->Gateway Controllers (RTP Portals Network Element) Data Structure
Parameter
.
Border Control Point 7200 conguration

The chapter is organized as follows: "Conguring the BladeCenter-T service node" (page 88) "Conguring the BladeCenter-T service data" (page 88) "Conguring the BladeCenter-T" (page 98) "Stand-alone instantiation" (page 111) Procedure 24 "Instantiating the service cluster" (page 117) "Run-Time Service Conguration Parameter Mapping" (page 86)
Conguring the BladeCenter T service node

The conguration of either variant of the BCP service node is built on the RTP Portal NE as represented in the RTP Portals data structure. For BladeCenter T service nodes, the platform-level conguration parameters are harvested from the RTP Portal NE. All service-level conguration is contained in the Media Portal Cluster data structure. See the Run-Time Service Conguration Parameter Mapping for detailed mapping of the location of service-level conguration parameters for each service node variant.
Conguring the BladeCenter T service data

The Media Portal Cluster entity contains the common service data conguration information and the BCP logical service instances (both standalone and clustered) that run on the BladeCenter T. The common service data is an abstraction specic to the BladeCenter T platform that is used to dene a common run-time service context that is common to all service instances in a service cluster. The information contained in the Media Portal Cluster data structure includes: Service Instances (denition of each active BCP service instance in the cluster). Conguration Parameters (the operational service conguration that runs by each active instance). Fault-tolerance (the parameters that dene the Peering-Plane used by BCP service instances for intracluster communications). Static Routes (an easier way to manage the conguration of static routes).
.
89
Session Managers (data structure that enables specication of the MCP SIP Session Servers that are to receive service). Gateway Controllers (data structure that enables specication of the CS 2000 Gateway Controllers that are to receive service). See the Media Portal Cluster: Data Structures for a more comprehensive listing of the conguration parameters present in this data structure.
Table 3 Media Portal Cluster: Data Structures Data type Service Instance Data (Defines each unique active Service Instance. This data can recur up to seven times.) Parameter name Service ID Parameter Type: Integer Range: 06 Parameter description The unique Service Identifier associated with this logical BCP service instance. The subnet mask that defines the scope of the network to which the Control IP address is associated. The subnet mask that defines the scope of the network to which the Net1 IP address is associated. The subnet mask that defines the scope of the network to which the Net2 IP address is associated. Listing of dataf illed Addresses (in Network Data folder) The IP address that is used for MPCP communications in the Control-Plane. The IP address that is used to convey media to/from Net1 (a logical interface) in the Media-Plane. The IP address that is used to convey media to/from Net2 (a logical interface) in the Media-Plane.
Control IPAddr SubnetMask
Listing of datafilled Subnet Masks (in Network Data folder)
Net1 Media IPAddr SubnetMask
Net2 Media IPAddr SubnetMask
Control IPAddr
Net1 Media IPAddr
Net2 Media IPAddr
.
Data type Configuration parameters (constitutes the Service Data that defines a service run-time environment that is common to all active Service Instances)
Parameter name Number of Port
Parameter Type: Integer Range: 110 000
Parameter description The number of media ports that the active Service Instances in this Service Cluster make available to provide service. Overrides Number of Port parameter present in the RTP Portal NE Blade Data. The lower bound on the range of media ports that can be allocated. Overrides Min Port Value parameter present in the RTP Portal NE Blade Data. The upper bound on the range of media ports that can be allocated. Overrides Max Port Value parameter present in the RTP Portal NE Blade Data. ***Do not change.*** This is an engineered value related to the number of simultaneous sessions. The threshold at which a Critical Alarm is raised to report that the number of media ports in use meets or exceeds the percentage of the total available. Overrides the CriticalPortU sageAlarmLevel parameter present in the RTP Portal NE Config Parm Group BladeRunner. The threshold at which a Major Alarm is raised to report that the number of media ports in use meets or exceeds the percentage of the total available. Overrides the MajorPortUsageAlarmLevel parameter present in the RTP Portal NE Config Parm Group BladeRunner.
Min Port Value
Type: Integer Range: 102665 535
Max Port Value
Call Legs
Type: Integer Range: 102665 535 Type: Percent Range: 0100 Default= 90
Critical PortUsage Alarm Level
Major PortUsage Alarm Level
Type: Percent Range: 0100 Default= 80
.
91
Data type
Parameter name Minor PortUsage Alarm Level
Parameter Type: Percent Range: 0100 Default= 50
Parameter description The threshold at which a Minor Alarm is raised to report that the number of media ports in use meets or exceeds the percentage of the total available. Overrides the MinorPortUsageAlarmLevel parameter present in the RTP Portal NE Config Parm Group BladeRunner.
Long Call Duration
The number of times the Idle Session Audit must run for an active session to be considered a Long Call. After classification as a Long Call, the session is either terminated autonomously by the Media Portal Service, or it is reported to the controlling Call Server. Overrides the LongCallDuration parameter present in the RTP Portal NE Config Parm Group BladeRunner.
Long IdleDuration
The number of times the Idle Session Audit must run for a validly idle session to be considered a Long Idle. After classification as a Long Idle, the session is either terminated autonomously by the Media Portal Service, or it is reported to the controlling Call Server. Overrides LongIdleDuration parameter present in the RTP Portal NE Config Parm Group BladeRunner.
Idle Session Audit Period
Type: Milliseconds Range:
The period of the Idle Session Audit.
.
Data type
Parameter name
Parameter 03 600 000
Parameter description Overrides IdleSessionAudit Period parameter present in the RTP Portal NE Config Parm Group BladeRunner. The interval during which the Poll Timer delays starting up after the service first initializes. Overrides PollTimerDelay parameter present in the RTP Portal NE Config Parm Group "BladeRunner".
Poll Timer Delay
Type: Milliseconds Range: 03 600 000
Poll Timer Interval
The period of the Poll mechanism. Overrides PollTimerInterval parameter present in the RTP Portal NE Config Parm Group BladeRunner. Controls the algorithm used to allocate and manage media ports. If checked (ON), this causes the Number of Port parameter to be ignored and every even-numbered port between the Min Port Value and the Max Port Value is allocated to provide service. If unchecked (OFF), port randomization mechanisms are used to ensure that the pool of allocated media ports is always rotated. Overrides StaticRTPPorts parameter present in the RTP Portal NE Config Parameter Group BladeRunner.
Static RTP Ports
Type: Checkbox ON|OFF
.
93
Data type Fault-tolerance Data (Defines aspects of the fault-tolerant framework)
Parameter name MultiCast IP
Parameter Listing of dataf illed Addresses (in Network Data folder)
Parameter description The IP address that is used in combination with the MultiCast Port as the basis for establishing the intracluster communications channel in the Peering-Plane. The UDP port that is used in combination with the MultiCast IP as the basis for establishing the intracluster communications channel in the Peering-Plane. The period between the heartbeats used to maintain the highly-available BCP Service Cluster. When checked, this parameter designates a non-redundant 1+0 standalone configuration of the BladeCenter T BCP. When unchecked, this parameter designates a redundant N+1 BCP Service Cluster configuration of the BladeCenter T BCP.
MultiCast Port
HeartBeat Interval
Type: Integer
Stand Alone
Type: Checkbox ON|OFF
Static Routes <Static Routes configured for this Service Cluster Session Managers There can be up to 20 total Call Servers (total of Session Managers and Gateway Controllers for each Service Cluster).
MPCluster Static Routes
Listing of datafilled Static Routes (in Network Data folder) Listing of datafilled Session Managers (in Network Element folder)
The Static Routes required to reach devices far off in the network.
Session Manager
Drop-down menu of available Session Managers. Overrides the Session Manager Data specified in the RTP Portal NE. Field specifying the frequency of the periodic MPCP RSIP to the controlling Call Servers. The value entered into this field overrides the value for the Discovery Probe
Discovery Probe Timer Period
.
Data type
Parameter name
Parameter
Parameter description timer field for each instance of Session Manager Data specified in the RTP Portal NE.
Gateway Controllers There can be up to 20 total Call Servers (total of Session Managers and Gateway Controllers for each Service Cluster.)
Gateway Controller
Listing of datafille d CS2K Gateway Controllers (in Network Element/Call Server 2000 Integration folder) Type: Milliseconds Range: 03 600 000
Drop-down menu of available GWCs that overrides the Session Manager Data specified in the RTP Portal NE.
Discovery Probe Timer Period
Field specifying the frequency of the periodic MPCP RSIP to the controlling Call Servers. The value entered in this field overrides the value for the Discovery Probe timer field for each instance of Session Manager Data specified in the RTP Portal NE.
A sample of the System Management Console rendering of the Media Portal Cluster data structure is shown in the System Management Console: Media Portal Cluster Data Structure.
.
Border Control Point 7200 conguration Figure 32 System Management Console: Media Portal Cluster Data Structure
95
Static Routes Data Structure

The Static Routes entity contains the static routes entries that are populated on the BladeCenter T service nodes as they come into service.
.
96 Conguration management Figure 33 System Management Console: Static Routes Data Structure
The procedure for creating a static route and adding it to the BladeCenter T BCP is described in Creating a static route and adding it to the BCP 7200 (also see System Management Console: Static Routes Data Structure).
Procedure 21 Creating a static route and adding it to the BCP 7200
Step
Action
At the System Management Console, 1 Ensure that the IP addresses of interest are dened in the site using the following steps: a. Open the Network Data and Mtc folder in the cong tree. b. Click the Addresses data structure to open the Addresses window.
.
97
c. Click the Add (+) button to open the Add Address window. d. Enter a unique Logical Name and IP Address pair. 2 3 Repeat this process to add as many IP address entities as required into the site. Identify specic network nodes or network resources that are external to the site (those that require special routing considerations) by using the following steps: a. Open the Network Data and Mtc folder in the cong tree. b. Click the External Nodes data structure to open the External Nodes window. c. Click the Add (+) button to open the Add External Node window. d. In the Add External Node window, identify the IP addresses in the site that require special route considerations by associating them with a unique external node name. Click Apply to commit this data. e. Repeat this process for each remote network node or network resource. 4 For these remote network nodes or network resources, identify the Gateways that can route to them and the subnet masks that dene their extent. Identify Gateways in the site by using the following steps: a. Open the Network Data and Mtc folder in the cong tree. b. Click the Gateways data structure to open the Gateways window. c. Click the Add (+) button to open the Add Media LAN Gateway window. d. In the Add Media LAN Gateway window, identify the IP addresses in the site that represent remote network gateways by associating them with a unique gateway name. Click Apply to commit this data. e. Repeat this process for each remote network gateway. 5 Identify the extent of the remote subnets in the site by following steps: a. Open the Network Data and Mtc folder in the cong tree. b. Click the Subnet Masks data structure to open the Subnet Masks window. c. Click the Add (+) button to open the Add Subnet Mask window.
.
d. In the AddSubnet Mask window, specify the subnet mask that denes the extent of the remote network and associate it with a unique subnet Mask Name. e. Click Apply to commit this data. f. 6 Repeat this process to dene the extent of each remote network.
Colocate the data identifying the remote network nodes and resources, remote network extent, and remote gateways into a static route denition that species when and how to reach those remote network nodes or resources. Perform the following steps: a. Open the Network Data and Mtc folder in the cong tree. b. Click the Static Routes data structure to open the Static Routes window. c. Click the Add (+) button to open the Add Static Routes window. d. In the Add Static Routes window, provide a Static Route Name to uniquely identify this static route. e. Identify the gateway that knows how to route to this remote network by selecting it from the Gateway pick-list (a listing of all Gateways dened in this site) f. Identify the remote network node or resource by selecting it from the Destination Network (External Node) pick-list (a listing of all External Nodes dened in this site).
g. Identify the extent of the remote network by selecting it from the Destination Subnet Mask pick-list (a listing of all Subnet Masks dened in this site). h. Click Apply to commit this data. End
Conguring the BladeCenter T

You congure the BladeCenter T BCP 7200 through the MCS System Management Console and through a combination of traditional RTP Portals datall (the RTP Portals Network Element used to describe the underlying BladeCenter T service nodes and Media Portal Cluster datall that denes the logical service context. You congure the BladeCenter T BCP with parameters that are consistent across service nodes. However, the location from which these parameters are taken varies with the service node type.
.
99
For BladeCenter T service nodes, the conguration is partitioned into separate data structures that represent service-level parameters (the Media Portal Cluster data structure) and platform-level parameters (the RTP Portal NE, as represented by the RTP Portals data structure). Most of the parameters present in the Media Portal Cluster still have equivalent representations existing in the RTP Portal NE. To overcome these ambiguities the Media Portal Cluster parameters override their equivalents in the RTP Portal NE (see "Run-Time Service Conguration Parameter Mapping" (page 86) for mapping of service conguration parameter locations for service node variants). You congure the BladeCenter T BCP 7200 by using a mix of data populated in existing data structures (for example, the engineering parameters in the RTP Portal NE) and conguration parameters that reside in the Media Portal Cluster data structure. Following are the steps to congure the BladeCenter T BCP 7200, including the population of the data structures.
Procedure 22 Conguring the BladeCenter T BCP 7200
Step
Action
At the System Management Console, 1 At this initial stage, all referenced data must be entered into the system. Addresses: The structure of this data does not change. Enter all Service IP addresses (physical and logical) into the Addresses data structure so that they can be referenced by label. This data is used by higher-level datall to identify network nodes, network resources, and to establish operational presence in the required service-planes.
Figure 34 Addresses list
.
External Nodes: This eld is for datall of static routes. It identies those network nodes and network resources that require special routing considerations. Gateways: The structure of this data does not change. This selection identies those network resources that can perform routing functions. This information is used in the RTP Portals data structure to dene the default route for the service node and to dene static routes in separate datall. Subnet Masks: This selection denes the scope of an address-space. This information is used to scope the extent of the service-planes in the Media Portal Cluster data structure and to dene static routes in separate datall. Static Routes: This selection is used for datall of static routes and denes the special routing considerations that need to be employed to access remote network nodes and network resources. Enter data into the Interface1 eld (pick-list of datalled IP Addresses) with the intended physical IP address for each BladeServer in the BladeCenter T chassis. This IP address is the bond0 physical address on the BladeServer and is also used to represent the BladeServer and the BCP service instance to the MCS OAM framework. Datall Servers parameters. This stage of conguration creates a logical representation of a server within which to group together all the data that denes a physical service node including physical IP address associations (the physical IP address bound during installation and commissioning). There must be a Server created for each service node (in other words, each hosting BladeCenter T BladeServer) so that it is adequately represented in the MCS OAM framework. The structure of this data does not change.
First, open the Media Portal Cluster window within the Network Elements and Media Portals navigation pane. Enter data into the Media Portal Cluster entities. This stage of conguration creates a logical representation of the BCP Service (Clustered or Stand-Alone) within which to group together all the data that denes the service. Next, click the Add (+) button to open the Add Media Portal Clusterwindow to create a Service Cluster. Enter a unique name for this Media Portal Cluster (for example, bctcluster1) and click Apply.
8 9
.
101
At this point the newly specied Cluster Name is associated with a default data structure and appears in the System Management Console navigation tree. 10 The Media Portal Cluster can be populated with the parameters that uniquely identify this cluster as well as all of the parameters that dene the service characteristics for this cluster. Service Instances: Data must be supplied that species the unique traits of each active service instance and therefore the number of BCP service instances in this cluster (in other words, an MPCP control IP address, and up to two media IP addresses for each Service Instance). One entry exists in this data structure for each Service Instance. These constitute the "N" active service instances in the N+1 fault-tolerance strategy (there is a single service instance dened for both 1+0 standalone and 1+0 service clusters). The numbers in Media Portal Cluster: Service Instances Datall correspond to steps a through e, that follow.
Figure 35 Media Portal Cluster: Service Instances Datall
11
a. Click the Service Instances data structure to open the Service Instances window for this Service Cluster. b. Click the Add (+) button to open the Add MPCluster Service Instances window.
.
c. Dene the Service Instance for this Service Cluster: Service ID: unique value (0-6) for each Service Instance in a Service Cluster. Control IPAddr SubnetMask: a pick-list of the Subnet Masks dened in this site that scopes the extent of the Control-plane. Net1 Media IPAddr SubnetMask: a pick-list of the Subnet Masks dened in this site that scopes the extent of the Media-plane to which this interface is connected. Net2 Media IPAddr SubnetMask: a pick-list of the Subnet Masks dened in this site that scopes the extent of the Media-plane to which this interface is connected. Control IPAddr: a pick-list of the Addresses dened in this site that identies the point of presence that this Service Instance occupies in the Control-plane. Net1 Media IPAddr: a pick-list of the Addresses dened in this site that identies one of the points of presence that this Service Instance occupies in the Media-plane. Net2 Media IPAddr: a pick-list of the Addresses dened in this site that identies one of the points of presence that this Service Instance occupies in the Media-plane.
d. Click Apply to commit this data. e. Repeat this process (up to 7 times) to add the desired number of Service Instances to this Service Cluster. 12 Conguration Parameters: These are data parameters that dene the operating service context shared by all service instances (all service instances in a cluster run the same service conguration to maintain service consistency). The numbers in Media Portal Cluster: Conguration Parameters Datall correspond to substeps a through d, following.
.
Border Control Point 7200 conguration Figure 36 Media Portal Cluster: Conguration Parameters Datall
103
a. Click the Conguration Parameters data structure to open the Conguration Parameters window for this Service Cluster. b. Click the Add (+) button for new, or the Change (-/+) button for existing, to open the Add MPCluster Cong Parameters window or the Edit MPCluster Cong Parameters window. c. Dene the new conguration parameters for this Service Cluster (see Media Portal Cluster: Data Structures for a description of each parameter). d. Click Apply to commit this data. 13 Fault tolerance: Data supplied to dene the characteristics of the channel used for intracluster communication between all cluster members. The numbers in Media Portal Cluster: Fault Tolerance datall correspond to substeps a through d, following.
.
104 Conguration management Figure 37 Media Portal Cluster: Fault Tolerance datall
a. Click the Fault Tolerance data structure to open the Fault Tolerance window for this Service Cluster. b. Click the Add (+) button for new, or the Change (+/-) button for existing, to open the Add MPCluster Fault Tolerance window or the Edit MPCluster Fault Tolerance window. c. Dene the new fault-tolerance parameters that dene the Peering-plane intracluster communications channel for this Service Cluster (see Media Portal Cluster: Data Structures for a description of each parameter). d. Click Apply to commit this data. 14 Static Routes: Provides a convenient interface for dening static routes for the BladeCenter T BCP (see Figure 38 "Media Portal Cluster: Static Routes Datall" (page 105) for more information). The numbers in Figure 38 "Media Portal Cluster: Static Routes Datall" (page 105) correspond to substeps a through d, following.
.
Border Control Point 7200 conguration Figure 38 Media Portal Cluster: Static Routes Datall
105
a. Click the Static Routes data structure to open the Static Routes window for this Service Cluster. b. Click the Add (+) button to open the Add MPCluster Static Routes window. c. Select one of the static routes dened in this site using the pick-list: (see d. Click Apply to commit this data. e. Repeat this data to add as many static routes to this BladeCenter T BCP as it needs to provide service. 15 Session Managers: (see Figure 39 "Media Portal Cluster: Session Managers datall" (page 106)) Call Server Data that identies the set of SIP Session Managers to which the BCP Service Cluster must advertise its availability to provide service (in other words, establish MPCP control sessions). The numbers in Figure 39 "Media Portal Cluster: Session Managers datall" (page 106) correspond to substeps a through e, following.
.
106 Conguration management Figure 39 Media Portal Cluster: Session Managers datall
a. Click the Session Managers data structure to open the Session Managers window for this Service Cluster.
Figure 40 bctcluster1 Session Managers dialog box
b. Click the Add (+) button to open the Add Session Manager window. c. Specify the following: Session Manager: Select one of the Session Managers dened in this site using the pick-list. Discovery Probe Timer Period: Specify the frequency at which the BCP service instances advertise their availability to provide service to this Session Manager.
d. Click Apply to commit this data.
.
107
e. Repeat this data to add as many Session Managers as necessary to this BladeCenter T BCP. There can be a maximum combined total of 20 Session Managers and Gateway Controllers associated with a BCP. 16 Gateway Controllers: (see Figure 41 "Media Portal Cluster: Gateway Controllers datall" (page 107)) Call Server data identies the set of CS 2000 Gateway Controllers to which the BCP Service Cluster must advertise its availability to provide service (to establish MPCP control sessions). The numbers in Figure 41 "Media Portal Cluster: Gateway Controllers datall" (page 107) correspond to substeps a through e, following.
Figure 41 Media Portal Cluster: Gateway Controllers datall
a. Click the Gateway Controllers data structure to open the Gateway Controllers window for this Service Cluster. b. Click the Add (+) button to open the Add Gateway Controller window. c. Specify the following: Gateway Controller: Select one of the Gateway Controllers dened in this site using the pick-list.
.
Discovery Probe Timer Period: Specify the frequency at which the BCP service instances advertise their availability to provide service to this Gateway Controller.
d. Click Apply to commit this data. e. Repeat this data to add as many Gateway Controllers as necessary to this BladeCenter T BCP. There can be a maximum combined total of 20 Session Managers and Gateway Controllers associated with a BCP. 17 Enter data for the RTP Portals Network Elements. The RTP Portals Network Element remains the fundamental conguration data structure for representing the hardware platform. The RTP Portals Network Element provides the BladeCenter T BCP with service node conguration data (for example, Engineering parameters) and a point of attachment into the MCS OAM Framework. It is the RTP Portal NE that enables the deployment of the BCP software, provides the channel for telemetry (Logs, Alarms, and Operational Measurements), and enables support for maintenance actions (Start, Stop, and Kill). In the context of the BladeCenter T BCP, each RTP Portals Network Element (BladeServer) represents a possible service node on which a BCP service instance can execute. The association of a BladeCenter T service node to the BCP Service is made through the new MPCluster name eld that is added to the RTP Portal NE data. After the association between service node and service is made, the BCP service instances can execute on the associated RTP Portal NEs and oat across the RTP Portal NEs to preserve service as faults occur. To specify a RTP Portal NEs membership in a BladeCenter T BCP Service Cluster, the following steps must be taken (see Figure 42 "RTP Portal NE: Association of MP Cluster Membership" (page 109)). The numbers in Figure 42 "RTP Portal NE: Association of MP Cluster Membership" (page 109) correspond to substeps a through e, following.
.
Border Control Point 7200 conguration Figure 42 RTP Portal NE: Association of MP Cluster Membership
109
a. First, open the RTP Portals window within the Network Elements or Media Portals navigation pane. b. Click the Add (+) button to open the Add RTP Portal window to create a new service node. c. The only consideration after creating a BladeCenter T RTP Portal NE is the MPCluster name eld used to associate a service node with the BCP service. The RTP Portal NE MP Cluster eld is populated by selecting entries from a pick list. The pick list contains an entry for each of the Media Portal Cluster dened in the Network Data. Each server participating in a Service Cluster (identied within the RTP Portals Network Element data structure) is assigned Cluster membership in this manner, thereby establishing a common association among the N+1 servers hosting the Cluster. Cluster membership is available only to the BladeCenter T BCP 7200. You must congure both of the supported BladeCenter T BCP congurations (the Stand-alone and the Service Cluster) as members of a Cluster. In the case of the BladeCenter T BCP Stand-alone, conguration is performed such that a 1+0 (1 Active
.
Service Instance and 0 Standby Service Instances) cluster is created. All Clusters are uniquely dened by the combination of a multicast IP Address and a multicast port specied in the fault-tolerance Data in the new Media Portal Cluster Network Data. However, what makes the Stand-Alone conguration unique in that only one Service Instance is congured. The BladeCenter T BCP fails to start if it detects MPCluster name=<none> in its datall. d. In the Management Consoles navigation pane, click Apply to create an instance of the RTP Portal NE data (for this service node). e. Populate the RTP Portal NE data structures. The only new considerations that come into play after populating the BladeCenter T RTP Portal NE data structures are: The Service Instance IP address provides the point of presence in the Management-plane (a separate IP address is specied in the Media Portal Cluster that provides presence in the Control-plane). The redundancy of the service-level conguration parameters that still reside in the RTP Portal NE but are not used by the BladeCenter T as they are superseded (for the BladeCenter T) by equivalent parameters present in the Media Portal Cluster datall. See the Table 2 "Service conguration parameters for the BladeCenter T" (page 86) for mapping of these parameters for each service node variant. You can repeat this process up to eight times to provide sufcient service nodes to support execution of seven active service instances and one standby service instance) to add the desired number of Service Node associations to a Service Cluster. Due to complex data dependencies, after an association is made between a service node and a Service Cluster (or <none>) as occurs after the BCP datall is committed, the only means of changing the association is through removal and recreation of the RTP Portal NE. End
.
111
BladeCenter T BCP service creation

The following activities must be performed to prepare and deploy the BladeCenter T BCP and to actively provide service in the network: Installation and commissioning of the base hardware (IBM BladeCenter T) and software (Red Hat ES 3) platforms. This ensures proper setup of such items as hardware, cabling, network connectivity, and IP address assignments. Conguration of both the BCP Service (Media Portal Cluster data) and the BCP service node (RTP Portals). Deployment of the service software to distribute the service logic to each of the BladeServers participating in the Service Cluster. The Service Instance must be started transitively (the START command must be issued from the System Management Console on each of the RTP Portal NEs that are members of the service cluster) for instantiation to occur and service to be provided.
These activities are described in more detail in the following sections. Deploy and start activities are very similar for standalone and Service Cluster congurations, but each is described separately for completeness.
Stand-alone creation
This section describes the deployment of Service software and the startup of the BCP service for a Stand-Alone BladeCenter T BCP service instance. The Stand-Alone BCP Service is a single nonredundant instance of the service that runs independently of all other instances. Even though the Stand-Alone BCP Instance is operationally different from the BCP Service Cluster in a number of ways, it is congured as if it were a 1+0 non-redundant Cluster. That is, one active service instance and zero standby instances. The Stand-Alone Service Instance is congured only with one element of Service Instance Data (in Network Data => Media Portal Cluster). The characteristics that distinguish a Stand-Alone BCP Instance from a BCP Service Cluster, specically a 1+0 fault-tolerant Service Cluster (which is also congured with a single active service instance), are the setting of the Stand Alone (Boolean) parameter in the Media Portal Cluster Fault Tolerance data. After the Stand Alone Boolean is congured, it causes a nonredundant 1+0 (a single active Service Instance and no Standby Service Instance) cluster to form. the number of associated RTP Portal NEs. A nonredundant 1+0 cluster is associated only with a single service node; a fault-tolerant 1+0 service cluster is associated with two service nodes.
.
After this conguration is instantiated, it effectively creates a one-to-one association of the Stand-Alone BCP service instance with the target BladeServer. A single BladeCenter T chassis can host up to eight separate Stand-Alone BCP Instances, one on each of the available BladeServers in the BladeCenter T chassis (see Figure 43 "Stand-Alone BCP service instances (Logical View)" (page 112)).
Figure 43 Stand-Alone BCP service instances (Logical View)
You perform the following activities in the course of introducing a new Stand-Alone BladeCenter T BCP service instance into a site: Installation and commissioning of the base hardware and software platforms. Conguration of the service. You can change the BCP Service conguration at any time, but is picked up only by the service after the RTP Portal NE is started. The key piece of conguration information that distinguishes the 1+0 Stand-Alone Service from the 1+0 redundant Service Cluster is the setting of the Stand Alone conguration parameter in the Media Portal Cluster Fault Tolerance data.
.
Border Control Point 7200 conguration Procedure 23 Creating the service
113
Step
Action
At the System Management Console, 1 2 Navigate to the RTP Portals folder in the navigation pane. Create an RTP Portal NE representing the BladeServer targeted to participate in this 1+0 Service Cluster (this is the only RTP Portal NE associated with this Cluster, making it a standalone). Open the NE Maintenance window and click Deploy to dispatch the service software to the BladeServer. After an association is made between an RTP Portal NE and a Service Cluster, the only way to change the association is through deletion and recreation of the RTP Portal NE.
After the Service Instance is successfully deployed, it must be started so that instantiation of the run-time structures occurs and the service can be offered. Navigate to the RTP Portals Network Element representing the BladeServer participating in this 1+0 Service Cluster.
Open the NE Maintenance window and click Start to start up a BCP service instance on this BladeServer. End
.
114 Conguration management Figure 45 Starting NE Maintenance
As the BCP service instance on the target BladeServer comes into service, it retrieves its conguration data from the MCS Database Server. The BCP service instance determines that it is congured to participate in a Cluster and then locates the specic Cluster conguration (Media Portal Cluster data). Instantiation of the service proceeds using the Media Portal Cluster Data to congure the service. Some of the rst processes started by the BCP service instance are those that support the N+1 fault-tolerant framework (for example, they allocate the congured multicast address and port, and start the reliable messaging framework to open the intracluster communications channel). As the N+1 fault-tolerant Framework Processes come up, they establish the Cluster in run-time. Since this is the rst BCP service instance in the Cluster, it is determined to be an active instance. In fact, since this is a Stand-Alone conguration, this is the only instance. After a BCP service instance is congured as active state, it issues MPCP RSIP messages to all of its congured Call Controllers (the Session Managers and the Gateway Controllers as congured in the Media Portal Cluster Data) to advertise its ability to provide service. At this point, you can call upon the BCP service instance to service calls.
.
Border Control Point 7200 conguration Figure 46 BladeCenter T BCP 7200 standalone service deployment
115
Service Cluster Instantiation

This section describes the deployment of service software and the startup of the BCP service for a BladeCenter T BCP 7200 fault-tolerant Service Cluster. The deployment phase places the service software on the target BladeServers, and the start phase causes the instantiation of run-time structures so that the BCP Service Cluster forms and begins to actively provide service. The BCP Service Cluster is an N+1 (N active Service Instances, and 1 standby Service Instance) redundant collection of BCP service instances. Each instance of the BCP Service that runs in the Cluster coordinates its activities with the other member instances. Service coordination takes place over the intracluster communications channel (the Reliable Messaging Framework) that is used to form (using the Election Protocol) and maintain the Cluster (using the Checkpointing functions). When forming an N+1 Cluster, it is always the nal instance joining the Cluster that becomes the standby instance. This ensures that a Cluster begins to provide service as soon as it is started and grows to engineered operational capacity as quickly as possible before electing a standby instance. The run-time characteristic that distinguishes the BCP Service Cluster from a Stand-Alone BCP service instance is that a Service Cluster is usually congured with multiple Service Instance Data elements (in Network Data => Media Portal Cluster).
.
The exception to this is the 1+1 fault-tolerant service cluster, which is congured much like a 1+0 standalone service instance, except for the setting of the standalone conguration parameter in the cluster data. The 1+1 fault-tolerant service cluster is also distinguished from the 1+0 standalone service by the fact that it contains an active service instance that checkpoints its data to a standby service instance, which is available to take over service processing if a failure occurs. After any of the BCP service instances in the Cluster are instantiated, they can run on any of the BladeServers participating in the Cluster. A one-to-one relationship between the Service Instances and the service nodes does not exist. A single BladeCenter T chassis can host a BCP Service Cluster of up to 7+1: seven active BCP service instances and one standby BCP service instance (see Figure 47 "BladeCenter T BCP Service Cluster (Logical View)" (page 116)).
Figure 47 BladeCenter T BCP Service Cluster (Logical View)
.
117
The following activities are performed in the course of introducing a new BCP Service Cluster into a site: installation and commissioning of the base hardware and software platforms conguration of the service and the service nodes. You can change the BCP Service conguration at any time but (for the most part) is picked up only by the service on startup.
Procedure 24 Instantiating the service cluster
Step
Action
At the System Management Console, 1 Navigate to the RTP Portals Network Elements representing each of the BladeServers that participate in this (1+0) Service Cluster (a sample 1+0 fault-tolerant Service Cluster is presented for demonstration purposes). For each of these RTP Portal NEs ( two RTP Portal NEs are required to form a 1+0 fault-tolerant Service Cluster), open the NE Maintenance window and click Deploy to dispatch the Service software to the associated BladeServer.
After the member Service Instances are successfully deployed, they must be started individually so that instantiation of the run-time structures occurs, the Cluster forms, and service can be offered. Start up of individual Service Instances occur any time after the service software is deployed to the BladeServers participating in the Cluster. This process is repeated for each of the RTP Portal NEs representing a member of the Cluster. Navigate to the RTP Portals Network Element representing a BladeServer participating in this 1+0 Service Cluster.
.
4 5
Open the NE Maintenance window. Click Start to start up a BCP service instance on this BladeServer. Issuing the Start command to the RTP Portal NE representing the other RTP Portal NE associated with this fault-tolerant Service Cluster occurs in a similar fashion. As the BCP service instance on the target BladeServer comes into service, it retrieves its conguration data from the MCS Database Server. The BCP service instance determines that it is congured to participate in a Cluster and then locates the specic Media Portal Cluster data. Instantiation proceeds using the Media Portal Cluster data to congure the service. The other BCP service instance starts up in a similar fashion. Some of the rst processes started by the BCP service instance are those that support the N+1 fault-tolerant Framework (for example, they allocate the congured multicast address and port, and start the reliable messaging framework to open the intracluster communications channel). Since this is the rst BCP service instance in the 1+0 Cluster, it is determined by the N+1 fault-tolerant framework to be an active instance. As the second BCP Instance starts up and joins the Cluster, the N+1 fault-tolerant framework determines that since this is congured as a 1+0 Cluster, this instance must be the Standby. This second BCP Instance operates in Standby mode, checkpointing all service data from the active Service Instance and monitoring its status, while waiting for the opportunity to assume activity in the event that the active Service Instance encounters a fault. After a BCP service instance is congured as active, it issues MPCP RSIP messages to all of its congured Call Controllers (Session Managers and Gateway Controllers as congured in the Media Portal Cluster data) to advertise its ability to provide service. After this point, the Cluster comes into service, and the active BCP service instance is called on to service calls. In the course of processing service requests, all active BCP service instances communicate inside the Cluster to checkpoint service data to the Standby Service Instance and to convey status so that the Cluster remains synchronized and able to survive the failure of one of its members. End
.
Troubleshooting the IBM BladeCenter hardware 119
Troubleshooting the IBM BladeCenter hardware

This chapter describes the troubleshooting of BladeCenter hardware problems.
IBM BladeCenter hardware failure and replacement

ATTENTION
If any support or warranty contracts exist on the equipment, Nortel recommends that you use these support agreements to replace the hardware that is identied as failed. If you do not use those agreements, you can void the remaining time on the support agreements.
BladeCenter modules
The general steps for physically removing and installing these modules are the same (The blower modules are somewhat different. See the"Blower modules" (page 121))
CAUTION
Make sure you have the replacement on hand before removing any modules (including such items as the blower and the management module). If they are removed and not replaced immediately the air ow causes the chassis and other components to overheat and become damaged. Procedure 25 Removing a module
Step
Action
At the bay, 1 2 Pull down on the orange release lever until it stops. This slides the module out of its bay approximately half an inch. Grab the body of the module and slide it completely out of its bay. End
Installing a module
Step Action At the bay, 1 Make sure the release lever is fully open.
.
2 3
Slide the module into its bay until it stops. Push the release lever closed. Additional instructions specic to a particular module are provided as needed. End
Procedure 26 Replacing management modules
Step
Action
At the bay, 1 To replace an existing management module, make sure all existing sessions (for example, web or telnet) to the management module are shut down. Unplug the KVM and network cables from the management module. Remove the existing management module from its bay. Install the new management module. Reconnect the KVM and network cables to the new management module. Ensure that the OK LED on the back plate of the module is lit. To congure the new management module, contact your next level of support. It is necessary to only congure the primary management module (for example, with IP addresses); the secondary management module does not need to be explicitly congured. In the event that the primary management module fails, the secondary management module automatically inherits the settings from the primary management module. It is necessary that both management modules are connected to the same network subnet. End
2 3 4 5 6 7
Procedure 27 Replacing an existing ESM (I/O module)
Step
Action
At the bay,
.
1 2 3 4 5 6
Unplug the network cables from the I/O module. Remove the existing I/O module from its bay. Install the new I/O module. Reconnect the network cables to the new I/O module. Ensure that the OK LED on the back plate of the module is lit. Contact your next level of support to congure the new I/O module. End
Procedure 28 Replacing power supply modules
Step
Action
At the bay, 1 2 3 4 5 6 Unplug the power cable from the power module. Remove the existing power module from the bay. Install the new power module. Reconnect the power cable to the new power module. Ensure that the other end of the power cable is connected to a 220V PDU or 220V AC power outlet. Ensure that the DC and AC power LEDs on the back plate of the module are lit. End
Blower modules
The procedure for removing and installing a blower module is slightly different (in the release mechanism) than the other BladeCenter modules. If you replace an in-service blower module, replace it within two minutes during service.
Procedure 29 Removing a blower module
Step
Action
At the bay,
.
1 2
Press the orange release button on the blower module handle. Grab the handle and slide the module completely out of its bay. End
Procedure 30 Installing a blower module
Step
Action
At the bay, 1 To install a blower module, slide the blower module into its bay until the release button clicks. End
BladeServers (x-blade)
Procedure 31 Replacing an existing single-slot blade (or the processor half of a dual-slotblade)
Step
Action
At the bay, 1 2 Shut down the BladeServer operating system. Power down the BladeServer by pressing the white power-control button for the blade (located behind the control panel door on the front of the blade; the panel door ips down to expose the power-control button). Wait about 30 seconds to let the drives on the blade spin down. Open (pull apart) the two release levers until they stop. This slides the blade out of its bay about half an inch. Grab the body of the blade and slide it completely out of its bay. (Note that the spring-loaded doors cover the empty bay automatically after the blade is removed.) Make sure the release levers on the new BladeServer are fully open. Slide the new BladeServer into its bay until it stops. (Note that the spring-loaded cover doors push out of the way as you slide the new BladeServer into place.)
.
3 4 5
6 7
8 9 10 11
Push the release levers on the new blade fully closed. Power up the new BladeServer by pressing the power-control button for the blade. Ensure that the green power LED on the front panel of the blade is lit steadily; a blinking LED means that the blade is not powered up. Congure and install the software as required for the application. End
Expanding the BladeServer (x-blade-combo)

To replace the nonexpansion processor half of an existing dual-slot blade, see "Blade Servers (x-blade)" (page 122). To replace the expansion half of an existing dual-slot blade, see "Replacing the SCSI drive" (page 123).
Replacing the SCSI drive

The expansion half of a dual-slot blade contains up to two hot-swappable SCSI drive trays that you can replace without having to power down the blade itself.
Procedure 32 Replacing the SCSI drive
Step
Action
At the bay, 1 2 3 4 5 6 To replace an existing SCSI drive, make sure that the drive is spun down (stopped spinning). Slide the drive tray out of its bay. Ensure that the tray release handle for the new drive tray is fully open. Install the new drive tray into its bay. Push the tray release handle down until it is fully closed. Verify that the green hard disk activity LED is ashing, indicating that the drive is accessed. If Redundant Array of Inexpensive Disks (RAID) is congured for this drive, the new drive is automatically rebuilt upon insertion. The system continues to run while the rebuild occurs. To check the status
.
of the rebuild, run /usr/local/bin/getScsiInfo. This tells you how much of the rebuild is complete and how much is left. Depending on the size of the drive, the rebuild can take a few hours to complete. End
BladeCenter chassis
Procedure 33 Replacing the BladeCenter chassis
Step
Action
At the bay, 1 2 3 4 5 If the chassis itself must be replaced, shut down and remove the BladeServer blades and expansion units. Power down the BladeCenter by disconnecting the power cables from the power modules. Remove all cables connected to the BladeCenter modules. Remove the modules (management and I/O) from their respective bays. On the back panel of the BladeCenter chassis, disengage the shipping brackets (located about halfway down on either side of the back panel) by sliding them inwards, towards the blower module bays. Unscrew the thumbscrews located at the bottom corners of the back panel, and then pull them up and out until the chassis slides out about half an inch. Grab the chassis body and slide the chassis out about halfway. While supporting the chassis, disengage the release levers on the sides of the chassis and then pull the chassis the remainder of the way out. To install a new chassis, reverse the preceding steps. End
7 8
.
125
Accounting management
Functional description
The BCP 7200 does not perform accounting management. However, an indication that a BCP 7200 component is used during a session is provided in the accounting records. For more information about accounting, see Accounting Manager Fundamentals (NN42020-144).
.
126 Accounting management
.
127
Performance management
The HALayer OM Group supports the BladeCenter T BCP. This OM Group consists of the following in-band performance measurements: statusCntMeter showing the number of internal status change events generated by the fault-tolerance mechanisms on this service node.) updateCntMeter showing the number of service instances that join the cluster from the perspective of this service node.) chkPointsRcvdMeter showing the number of checkpoints received by this service node.) chkPointsSentMeter showing the number of checkpoints sent by this service node.) activeInstancesMeter showing the number of active services instances in the service cluster associated with this service node.) standbyInstancesMeter showing the number of standby service instances in the service cluster associated with this service node.)
You can monitor BCP 7200 performance through the System Management Console by viewing Operational Measurements (OMs). For more information about BCP 7200 OMs and the viewing of these OMs, see the System Management Console User Guide (NN42020-110). OMs provide statistical information about the server operations and performance. OMs are represented in terms of groups, which contain registers (counters and gauges) that provide performance-related data. The System Manager scans OM Group registers at a congured interval. Administrators can view the OM information associated with a selected component in the OM Browser at any selected point in time (corresponding to the launching of the OM Browser). Congure the OM scan cycle using the OAM conguration options available in the System Management Console. Two types of OMs exist: active and holding. Active OMs are displayed as they are reported by the server to the Management Server/Management Console. Holding OMs are already archived to les on the server hosting the active System Manager.
.
128 Performance management
Viewing operational measurements

Both the active and holding OM on the System Manager are viewed in the System Management Console OM browser. For information about using the browsers, see System Management Console User Guide (NN42020-110). The information listed in the following table appears in the OM browser.
Table 4 OM details displayed in the OM browser Information Group Name TimeStamp InstanceName Register Name Register Value Description The name of the OM group where the scanned information resides. The instance the OM information is scanned. The name of the service originating the OM information. The name of the OM register at the time of the scan. The value of the OM register at the time of the scan.
BCP 7200 OMs

The BCP 7200 generates the OMs described in Table 5 "BCP 7200 general OMs" (page 128). Additional OMs related to the use of the BCP 7200 are pegged by the Session Manager. For more information about this component, see Operational Measurements Reference (NN42020-704).
Table 5 BCP 7200 general OMs OM Name Go Online Count Format Integer Definition Counter tracking the number of times the BCP 7200 is commanded to an online state. The online state can be commanded through the System Management Console or it can be auto recovered from a service-denying alarm. Counter indicating number of times service is denied through the BCP 7200 due to problems or lack of resources. Counter indicating number of create connection messages received. Counter indicating number of create connection messages processed. Counter indicating number of delete connection messages received. Counter indicating number of delete connection messages processed. Counter indicating number of modify connection messages received.
Denied Service
Integer
Received Create Connection Count Processed Create Connection Count Received Delete Connection Count Processed Delete Connection Count Received Modify Connection Count
Integer Integer Integer Integer Integer
.
BCP 7200 OMs 129
OM Name Processed Modify Connection Count Received Response Count Processed Response Count RSIP Count Retransmit Count Audit Cycle Sequence IDCount Total Number Connections Removed Count ConnsRemoved LatestCycle RTPMPPortUsageMeter RTPMPAvailableBladesMe ter RTPMPActiveBladesMeter NumEntriesInConnMapMe ter PreExistingConnections RecoveryModeFailures NumConnsRecovered <bladex>RecoveryPreExis tingConns <bladex>RecoveryNumCo nnsRecovered
Format Integer Integer Integer Integer Integer Integer Integer Integer
Definition Counter indicating number of modify connection messages processed. Counter, tracks the number of response messages received Counter that tracks the number of response messages processed Counter that tracks the number of RSIP message sent. Counter that tracks the number of messages retransmitted. Counter that tracks the number of audit cycles which occur. Counter that tracks the total number of connections removed across all audit cycles. Counter that tracks the total number of connections removed (recovered) by the latest idle stream audit cycle. Meter showing number of ports in use. Meter showing number of blades available to provide service. Meter showing number of blades with active connections. Meter showing the number of connections in the host CPU connection map. Meter showing the total number of connections that the Host CPU finds during host recovery. Meter showing the number of media blades to which control cannot be reestablished during host recovery. Meter showing total number of connections reconstructed during the last host recovery action. Meter showing the number of connections discovered during the last blade recovery action. Meter showing the number of connections reconstructed during the last blade recovery action.
Integer Integer Integer Integer Integer Integer Integer Integer Integer
.
130 Performance management
OMs generated by the Session Manager for the BCP 7200 are listed in Table 6 "Session Manager OM group Media Portal" (page 130).
Table 6 Session Manager OM group Media Portal OM Name MediaPortalSelectedFromDefau ltPoolCount MediaPortalResourceUnavaila bleCount MediaPortalInsertedCallCount Format Integer Definition BladeUDPIOControllerFactory: Each time a BCP 7200 is selected from the default resource pool, this OM counter is incremented. BladeUDPIOControllerFactory: Each time a BCP 7200 is inserted but has no resource available, this OM counter is incremented. BladeUDPIOControllerFactory: Each time a BCP 7200 is inserted for a call, this OM counter is incremented. BladeUDPIOControllerFactory: Each time a BCP 7200 is selected from a Media Portal Group, this OM counter is incremented. Tracks the number of Create Connection requests. Tracks the number of Delete Connection requests. Tracks the number of Modify Connection requests. Tracks the number of Disable Connection requests. Tracks the number of response messages received. Tracks the number of RSip messages received.
Integer
Integer
MediaPortalSelectedFromGrou pCount CreateConnectionCount DeleteConnectionCount Modify ConnectionCount DisableConnectionCount ResponseReceivedCount RSipReceivedCount
Integer
Integer Integer Integer Integer Integer Integer
.
131
Security and administration

This chapter is organized as follows: "Security overview" (page 131) "Network-level security functions" (page 131) "BCP 7200 component-level security functions" (page 132) "User administration" (page 133)
Security overview
One function of the BCP 7200 is to secure the media interface to the MCS Services Network. The securing of the media layer is achieved through a combination of methods at the network level and the component (BCP 7200) level.
Network-level security functions

At the network level, media layer security is achieved by the randomization of the IP addresses/ports used for multimedia sessions and use of NAPT (Network Address Port Translation) technology to obscure the network topology of the MCS Services Network.
Media Blade (IP address) randomization

After a multimedia session requests resources, the BCP 7200 selects an appropriate media blade to host the session. Media blade selection determines the specic IP address that is made available to the media streams for the session. During the selection of a media blade, the port usage of each available media blade is queried to determine the number of available ports for each. The media blade that has the most available ports is selected. This method of selection provides randomization and helps distribute the session load across the media blades.
.
132 Security and administration
Port randomization
After the BCP 7200 is deployed, each media blade is congured with a pool of ports containing a specic number of ports in a specic range based on conguration data (Number Ports, Min Port Value, Max Port Value, respectively). As multimedia sessions are initiated, a port is chosen from the port pool associated with the selected media blade. For nonstatic port congurations (Static RTP Ports is congured to be false), after a multimedia session is complete, associated ports are deallocated from the pool, and new replacement ports are allocated to the pool. The deallocation of used ports and allocation of replacement ports provides randomization in the port pools for the media blades.
NAPT function
To obscure the network topology, the BCP 7200 uses the NAPT functionality to secure the multimedia sessions so that topology information does not leak. Multimedia sessions are secured by maintaining a list of media ports (NAPT table) that are in use within active multimedia sessions. Only packets that arrive on these active ports are processed. Packets which arrive on nonactive ports are rejected.
BCP 7200 component-level security functions

The BCP 7200 component also contributes to system security by opening and closing media ports only in response to requests from the Session Manager and by rejecting any unauthorized packets that arrive on an active connection.
Authenticated requests
All requests to manipulate the media resources on the BCP 7200 originate from the Session Manager. The Session Manager ensures that all requests are made by, or made to, a valid service subscriber. In this way, the Session Manager effectively authenticates all requests. In addition, the portion of the BCP 7200 that processes these requests to manipulate the media resources resides safely within the network.
Packet lter or rewall

As packets are received, the BCP 7200 analyzes each packet to ensure the following: The data format is RTP/RTCP/UDP, as indicated by the session description. All other packet types are discarded.
.
User administration
133
The source or destination addresses match the expected source or destination addresses indicated in the session description. Packets that do not have a matching source or destination address are discarded. The source or destination ports match the expected source or destination ports indicated in the session description. Packets that do not have a matching source or destination port are discarded.
User administration
Basic administrative tasks for the BCP 7200 are covered in the Upgrade, Conguration, and Fault sections of this document. Other basic administrative tasks related to the System Management Console are covered in the System Management Console User Guide (NN42020-110). The BladeCenter T BCP service is managed through the member RTP Portal NEs. It is through manipulation of the state of the RTP Portal NEs that the BladeCenter T BCP service can be transitively brought into, and out of, service. Administrators basically manage the clusters by managing the network elements. Table 7 "BCP 7200 service management command reference" (page 133) contains a detailed explanation of the transitive service management. In this table, Initial Active is the rst service node to host an active service instance. N+0 is the state of the service cluster if a standby service instance does not exist (as is the case when the service cluster is coming into service, the service cluster is operating in failure-mode, or when the service cluster is being removed from service). N+1 is the state of a fully-formed and fault-tolerant service cluster (as is the case if the service cluster is operating with all active service instances providing service and a standby service instance that is ready-and-able to support takeover of any failed active service instance).
Table 7 BCP 7200 service management command reference BladeCenter T N+1 redundant service cluster (target server/instance) Initial active Start Begin providing service with first active instance. Expand service capacity with new active instances. n/a Bring stand by instance into service. Establish cluster redundancy n/a n/a N+0 (active) N+1 (active) N+0 (standby) N+1 (standby) Last active
.
BladeCenter T N+1 redundant service cluster (target server/instance) Initial active Stop Graceful shutdown: finish proces sing existing sessions, no new sessions established. No takeover. Kill Hard stop: Stop providi ng all service immediately; clear all sessions. No takeover (no standby service instance) Hard stop: Stop providin g all service immediately; clear all sessions. Takeover occurs. This active service instance and all hosted sessions begin running on the standby. The Cluster loses redundancy. Hard stop: Stop providi ng all service immediately; clear all sessions. n/a Hard stop: Stop providing service immediately. Hard stop: Stop providing all service immediately; clear all sessions. No takeover (no standby service instance) Graceful shutdown: finish proces sing existing sessions, no new sessions established. No takeover. Graceful shutdown: finish proces sing existing sessions, no new sessions established. No takeover. n/a Acquiesce: Stop providing service. Cluster loses redundancy. Graceful shutdown: finish proces sing existing sessions, no new sessions established. No takeover. N+0 (active) N+1 (active) N+0 (standby) N+1 (standby) Last active
The Cluster loses redunda ncy.
Stand-alone management
Manage the Stand-alone BladeCenter T BCP (telemetry monitoring and state changed) through the RTP Portal NE entity in the Nortel System Management Console. You can view Logs, Alarms, and Operational Measurements in their respective areas of the System Management Console. Likewise, State Management (for example, Start, Stop, Kill commands) is performed through the RTP Portal NE Instance window, which permits the service to be transitively managed (see Figure 50 "BladeCenter-T BCP Stand-alone service management system" (page 136)).
.
User administration Figure 49 NE Maintenance commands
135
.
136 Security and administration Figure 50 BladeCenter T BCP Stand-alone service management system
.
User administration
137
Managing the Service Cluster

Manage a BladeCenter T BCP Service Cluster (telemetry monitoring and state changes) transitively through administrative coordination of the management functions of each individual RTP Portal NE participating in the Cluster (for example, bct11 and bct12):
Figure 51 NE Maintenance commands
Perform coordinated management of the collection of RTP Portal NEs associated with the Cluster by using the Nortel System Management Console. Logs, Alarms, and Operational Measurements are available for each associated RTP Portal NE and are viewable in their respective areas of the System Management Console. Likewise, perform State Management (for example, Start, Stop, Kill commands) in a coordinated fashion on the RTP Portal NEs associated to the Service Cluster to achieve the desired operational result on the service. Each RTP Portal NE is managed using the NE Maintenance window of the RTP Portal NE.
.
.
139
BCT conguration worksheet

Successful conguration of the BCP depends on the accurate capture of conguration information. The information that is required for provisioning the BCP should be collected prior to installation. If you congure all eight BCPs on the BCT, you keep a record of eight individual slots (one for each BCP, and each with its own set of attributes). The following table should be completed before proceeding:
Table 8 Information Required for Installation and Commissioning on the BCT platform Border Control Point Configuration Information Slot 1 Attribute Host card network address (Portal address) Host card netmask Host card default gateway Host card IP failover active Hostname Timezone Timeserver IP address 2 Host card network address (Portal address) Host card netmask Host card default gateway Host card IP failover active Hostname Timezone Timeserver IP address Example 47.104.10.145 255.255.255.0 47.104.10.1 YES RTP_04 US/Central 47.103.18.2 47.104.10.146 255.255.255.0 47.104.10.1 YES RTP_04 US/Central 47.103.18.2 Value
.
140 BCT conguration worksheet
Host card network address (Portal address) Host card netmask Host card default gateway Host card IP failover active Hostname Timezone Timeserver IP address
47.104.10.147 255.255.255.0 47.104.10.1 YES RTP_04 US/Central 47.103.18.2 47.104.10.148 255.255.255.0 47.104.10.1 YES RTP_04 US/Central 47.103.18.2 47.104.10.149 255.255.255.0 47.104.10.1 YES RTP_04 US/Central 47.103.18.2 47.104.10.150 255.255.255.0 47.104.10.1 YES RTP_04 US/Central 47.103.18.2
.
BCT conguration worksheet
141
47.104.10.151 255.255.255.0 47.104.10.1 YES RTP_04 US/Central 47.103.18.2 47.104.10.152 255.255.255.0 47.104.10.1 YES RTP_04 US/Central 47.103.18.2
.
142 BCT conguration worksheet
.
143
Appendix A Backup and recovery

This chapter is organized as follows: "Prerequisites" (page 143) "Backing up the BCP" (page 144) "Setting up system access for backup" (page 144) "Setting up the remote tape drive" (page 145) "Error scenarios" (page 151) "Restore" (page 148)
Prerequisites
ATTENTION
Before beginning any backup or restore operation involving the use of a remote tape device or remote le server, it is important to make sure that all nodes involved have their network interface congured to full-duplex mode. That includes both the server backed up or restored, the tape or le server itself, and any intermediate nodes in the network being traversed. All MCS servers are congured to autonegotiate. Thus, if the nodes that the servers communicate with are congured to auto negotiate, they are congured to full-duplex. If a server (involved in the backup or restore) is not running at full-duplex, this results in backup and restore times that are ten times normal.
The following prerequisites are required for a BCP 7200 tape backup or restore: remote DDS4 or Universal Serial Bus (USB) tape drive. The tape drive does not need to be within the network, but it must be attached to a machine that is visible to the server conducting the backup. tape in the remote tape drive. For USB drives, use a 20-GB tape. For SCSI drives, use a 12-GB tape.
.
144 Appendix A Backup and recovery
live 100Mbps Ethernet connection. IP address of the tape server. Linux install CD in the CD-ROM drive for server restore operations. server address information for server restore operations.
For remote backup or restore operations, all servers involved must be running at full duplex. The following are required for disk backup: a disk with sufcient space for copying contents of the les stored under the /admin directory. for remote backup, the IP address of the remote server.
When connecting a USB tape drive to the server, perform the following: Log on as root to the server where the tape drive is being connected or disconnected. Type the command /etc/init.d/volmgt stop and press Enter. Connect or remove the USB tape drive. When connecting the tape drive, use port 0. When connecting the tape drive, type the command /etc/init.d/volmgt start and press Enter. When connecting the tape drive, turn it on.
If you receive an error while installing a USB tape drive, seeProcedure 37 "Fixing an error in the installation of a USB tape drive" (page 152).
Backing up the BCP

The time required for backing up the BCP can vary depending on network trafc, remote operations, and the amount of data to be backed up. Three methods for backing up the BCP exist: remote tape remote disk local disk
Setting up system access for backup

Access to the system with root access is required to perform a backup. This access can be obtained through: a secure telnet session through the server network interface. If this is used and the telnet session dies, the associated process (backup in this case) dies as well.
.
Backing up the BCP
145
a telnet session through a terminal server to the server serial console interface.
Setting up the remote tape drive

A remote tape drive is required. The following procedure outlines the steps necessary to properly congure the remote tape drive if it is on an MCS server. Only DDS4 and USB tape drives are supported for backup and restore of the BCP Linux servers. This server supports only backup and restore from local disk. If the remote tape drive is not on an MCS server, you can skip this procedure. However, you must ensure that the remote shell operations from the server to be backed up are enabled on the remote tape drive server. To perform the commands in the following steps, you can log on as root (or the sysadmin user). However, if you log on as root, the use of sudo must be removed from the following commands.
Procedure 34 Setting up the remote tape drive
Step
Action
From the server 1 2 3 As the MCS server has to access the tape drive on the remote host, make sure it has the proper access to that host. Log on as sysadmin to the remote host. On the remote host, execute the following script, which enables the execution of remote shell commands from the server being backed up (or restored): sudo /usr/local/bin/mcp_enable_remote_sh.pl <MCP_Server_IP> where <MCP_Server_IP> is the BCP host IP address. 4 5 From the BCP 7200, log on as root. Verify that access to the remote host is congured correctly: rsh -l sysadmin <Tape_Server_IP> df -k <Enter> where <Tape_Server_IP> is the IP address of the remote host with the tape drive.
.
Output appears on screen, indicating that the target system is correctly congured for the restore operation. If not, contact your next line of support before continuing. After the backup (or restore) procedure is complete, execute the following command on the remote host to disable the execution of remote shell commands on the remote host: sudo /usr/local/bin/mcp_disable_remote_sh.pl End
Backing up the BCP

Ensure the remote tape drive is congured up correctly before proceeding with tape backup to a remote host. For more information, see "Setting up the remote tape drive" (page 145).
Procedure 35 Backing up to a tape drive
Step
Action
From a terminal server 1 2 3 4 5 Label the DDS4 tape with the BCP 7200 name and the date of backup. Insert the tape into the tape drive of the server that acts as the backup host. Log on as sysadmin to the BCP 7200. Type sudo /usr/local/bin/mcp_backup.pl <Enter> The user is prompted for the type of backup. Enter a selection to continue:
Select a backup operation from the following list: [1] Backup to remote Tape Drive [2] Backup to remote Disk [3] Backup to local Disk [4] Exit/Abort backup Please enter the number [1 to 4] of the type of backup to perform.
To back up to a remote tape, continue with the next step. For remote tape backup, proceed to step 9. For backup to a local disk, proceed to step 10.
.
Backing up the BCP
147
Next, the user is asked for the IP address of the host where the tape drive resides. Type the IP address and press Enter to continue. The machine logical IP address, not the physical address, must be used. Information regarding the remote tape drive appears, and the user is prompted to verify tape insertion. Verify the information and press Enter to continue.
<timestamp> Backup to remote tape drive /dev/rmt/0cn on host <Remote_Host_IP.<Remote_Host_IP> is alive. Please verify a tape is freshly inserted into the tape drive. Any preexisting data on the tape is overwritten. Press Enter when you are ready.....
If the tape needs to be rewound, the user is prompted to rewind the tape as shown in the following example. Press Enter to accept the Default (Y) and continue.
The tape needs to be rewound, current tape file No = 1, Rewind Tape? [Y]:
To back up to a remote tape, proceed to step 10. 9 For Remote Disk backup, the user is prompted for the IP address of the remote host:
Enter the IP address of the remote device (in dot notation):
10
For Remote and Local Disk backups, the user is prompted for the full path and lename of the backup le:
Enter the path/filename to write the backup file to:
11
The backup operation can require several minutes to complete. If the backup requires more than one tape, the system prompts the user to insert additional tapes as needed. When the backup is complete, remove the tape from the tape drive. Store the tape in a safe, dry location.
12
Review the backup log mcp_backup.pl to ensure the backup is successful. The log le is stored in the directory /home/sysadmin/bkup_restore, and the lename is mcp_backup.pl.log.<dayTimeStamp>. where <dayTimeStamp> is YYYY_MM_DD_HH:MM:SS. Log off the machine. From the remote host, disable remote access:
13 14
.
sudo /usr/local/bin/mcp_disable_remote_sh.pl <Enter> 15 Store the tape in a safe, cool, dry location. End
Restore ATTENTION
While restoring a BCP server from a backup, consider that the MCS backup procedure only backs up conguration information in the /admin directory rather than the OS and its associated patches. When a restore is applied, it is a reinstallation and the backup conguration data is restored afterwards. Since this is actually a fresh installation, the BCP patches must be applied after the installation. The /admin/portal.cfg le must be modied to include patchlevel=0 after the fresh installation and recovery using the VI editor. Note that if the le is not modied, this results in a failure to apply the BCP patches.
The following procedure lists steps to restore the BCP 7200 from tape. Ensure the remote tape drive is congured up correctly before proceeding with the restore. For more information, see "Setting up the remote tape drive" (page 145).
Procedure 36 Restoring the BCP 7200 from tape
Step
Action
From the terminal server 1 2 3 Establish a terminal session to the host CPU through the terminal server. Insert the installation CD. Reboot the system. After the system boots from the installation CD, the initial welcome screen appears. 4 Enter one of the following at the boot: prompt. serial-com1Installation requires the COM1 serial port. serial-com2Installation requires the COM2 serial port. serial-com2 is the required setting for a CPV5370 host CPU. kvmInstallation requires attached keyboard, monitor, and mouse.
.
Backing up the BCP
149
Note that the selection determines the permanent location of the system console. 5 The software loads and checks for existing disk partitions. The system will output results of the check and whether any partitions are created and formatted. Press Enter to proceed. The script presents the Conguration Data Selection screen. Select the third option. The restore assumes that the default backup settings are used. By default, the backup procedure backs up the /admin partition. This partition contains the conguration les. If some other partition is backed up, the backup cannot be used to perform a restore. The user is prompted for the restore type. Make the appropriate selection. If restoring from tape, the script contacts the remote tape server. If the tape is not rewound, the user is given the option to do so. When the tape is ready, the script continues. 9 The script prompts the user for the IP address of the remote machine. If restoring from a remote le, enter the lename. As the system restore overwrites any existing data, the script prompts for verication before beginning the operation. The rst phase of data conguration involves the following network-based items: Application typeA read-only value that is congured automatically by the installer and cannot be changed. It describes the type of application being installed. Platform typeA read-only value that is congured automatically by the installer and cannot be changed. This value is congured according to the hardware platform being congured. HostnameThe name given to the BCP 7200. Machine Logical IPThe IP address assigned to the BCP 7200. Default GatewayThe default gateway router assigned to the BCP 7200 host card. NetmaskThe network mask for the BCP 7200 host card. TimezoneThe timezone in which the BCP 7200 is physically located. Host IP failover activeThe true/false value that controls the host IP failover service. If the service is active, the host card uses its network interfaces in an active/standby conguration.
.
6 7
10
11 12
You are prompted with a validation screen. The second phase of data conguration involves the following items related to the media cards: Chassis IdentifyA number that uniquely identies the BCP 7200 chassis. As a chassis can contain two independent Media Ports, this value is specic to the chassis. The number must be between 0 and 255 inclusive. Do not assign the same chassis identier to multiple chasses on the same local network. Host card slot numberThe slot number in which this host card is located. It must be either seven, for side A of the chassis, or nine, for side B of the chassis. Media Blade Default GatewayThe gateway router that is assigned to each media card in the system. This IP address can be different than the gateway IP assigned to the host card. Blade MAC AddressesThe MAC addresses for each media card in the system. Each card (NET1 and NET2) includes two MAC addresses. NTP Clock SourceThe IP address of an NTP server from which the BCP 7200 obtains clock synchronization. There can be zero or more congured NTP clock sources.
13 14
The user is prompted with a validation screen. Next, the Date and Time Conguration screen appears. If the time is correct, press Enter. Otherwise, press N to make corrections using the local time. The user is prompted for passwords for root, nortel, and sysadmin. Passwords must be at least eight characters in length. The installer performs a basic validation of passwords. The script begins the restore. A progress indicator appears on screen. Next, the system is congured for specic BCP 7200 requirements. This step in the process takes approximately 5-10 minutes to complete. The system reboots. Remove the CD-ROM from the drive when it is ejected. As the system is powering on, hold down the F2 key to enter the BIOS setup. For security purposes, remove everything from the boot device list except the hard drive. Save and exit BIOS setup. The system reboots.
15
16 17
18 19

.
Backing up the BCP
151
20
When the system reboot process is complete, press Enter to boot the default image. After rebooting, the login prompt appears and the BCP 7200 is ready for software deployment. End
Error scenarios
This section provides information regarding error scenarios that can occur when a backup or restore operation is in progress. For the BCP 7200, log les are in the directory /home/sysadmin/bkup_restore/
Invalid IP address
If an invalid IP address is entered, an information message appears. Example output:
/usr/local/bin/mcp_backup.pl 47.47.47.46 no answer from 47.47.47.46 10:22:27 ERROR: System, 47.47.47.46, could not be pinged 10:22:27 Remote Backup verification failed, aborting backup process Logs are written to/export/home/sysadmin/bkup_restore/mcp_backup...
For restore operations, if an invalid IP address is entered after the ufsrestore command is executed, an information message is displayed. Example output:
ufsrestore rfsv sysadmin@47.47.47.47:/dev/rmt/Ocn 1Fri Feb 6 17:06:14 CST 2004 48.48.48.48: Connection timed out before Fri Feb 6 17:11:03 CST 2004
Connection to remote tape server is lost

If a BCP 7200 loses connection to the tape drive during a backup, the system displays error messages on the screen.
Example output
As the mcp_backup script hangs, type Ctrl-C to abort. (To kill the process from another session type=> kill -9 <pid>.)
.
Tape drive failure

If something happens to the tape drive during a backup, an information message appears. Example output:
DUMP: write: I/O error DUMP: write error 8320 blocks into volume 1 DUMP: Do you want to restart?: ("yes" or "no")
Answer no to this prompt. The script terminates and another backup can start. An information message appears on screen:
DUMP: The ENTIRE dump is aborted. 19:29:15 *************************************************** 19:29:15 An error occurred during one (or more) dump commands=> 19:29:15 DUMP: Do you want to restart? ("yes" or "no") DUMP: the ENTIRE dump is aborted. 19:29:15 DO NOT USE THIS BACKUP - a RESTORE USING THIS BACKUP WILL FAIL 19:29:15 Fix the associated problem, and perform another backup 19:29:15 *************************************************** 19:29:15 Dump command(s) failed. Aborting backup. Logs are written to /home/sysadmin/bkup_restore/mcp_backup.pl.log
Restoring from multiple tapes

When restoring from multiple tapes, if you press Enter before inserting the next tape into the tape drive, the restore process must be restarted. To recover, continue to press Enter until the restore program reports a Read error. The following message appears:
Logs are written to /export/home/sysadmin/bkup_restore/mcp_recover.pl.log.2004_0 3_24.12:49:35
After the message appears, restart the restore procedure.
USB tape drive installation error

Follow this procedure to x an error in the installation of a USB tape drive.
Procedure 37 Fixing an error in the installation of a USB tape drive
Step
Action
At the server,
.
Backing up the BCP
153
1 2 3 4
If you receive an error while installing a USB tape drive, reboot the server. Log on as root. Type the command shutdown -y -g0 -i6 Press Enter. End
.
.
Nortel Multimedia Communication Server 5100
Border Control Point Fundamentals

Copyright 2007, Nortel Networks All Rights Reserved. Publication: NN42020-108 Document status: Standard Document version: 01.04 Document date: 27 April 2007 To provide feedback or report a problem in this document, go to www.nortel.com/documentfeedback. Sourced in Canada The information in this document is subject to change without notice. The statements, congurations, technical data, and recommendations in this document are believed to be accurate and reliable, but are presented without express or implied warranty. Users must take full responsibility for their applications of any products specied in this document. The information in this document is proprietary to Nortel Networks. Nortel, Nortel (Logo), and the Globemark are trademarks of Nortel Networks. IBM, BladeCenter, and BladeCenter T are trademarks of IBM Corporation. Motorola is a trademark of Motorola, Inc. All other trademarks are the property of their respective owners.

Avaya BCP - NN42020-108 - 01.04 - BCP

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Avaya BCP - NN42020-108 - 01.04 - BCP

Încărcat de

Drepturi de autor:

Formate disponibile

Nortel Multimedia Communication Server 5100

Border Control Point Fundamentals

How to get help

Regulatory and license information

BCP Installation on the IBM BladeCenter T platform

Border Control Point 7200 VLAN tagging

Upgrading the Border Control Point 7000 series

Security and administration

BCT conguration worksheet Appendix A Backup and recovery

Procedure 10 Procedure 11 Procedure 12

New in this release

BladeCenter T Border Control Point

10 New in this release

12 New in this release

How to get help

Finding the latest updates on the Nortel web site

Getting help from the Nortel web site

Getting help over the phone from a Nortel Solutions Center

14 How to get help

Getting help from a specialist by using an Express Routing Code

Getting help through a Nortel distributor or reseller

Regulatory and license information

Red Hat Software

16 Regulatory and license information

18 Regulatory and license information

How this chapter is organized

BCP 7200 (IBM BladeCenter T)

Figure 2 IBM BladeCenter T exploded chassis

24 Overview Figure 4 N+1 fault-tolerant BCP Service Cluster (chassis view)

Interfaces and protocols

Interfaces and protocols

N+1 fault tolerance strategy

N+1 fault tolerance strategy

Conguring the BCP 7200

Restrictions and limitations for the BCP 7200

BCP 7200 management interface

Restrictions and limitations for the BCP 7200

Copyright 2007, Nortel Networks

Restrictions and limitations for the BCP 7200

BCP Installation on the IBM BladeCenter T platform

38 BCP Installation on the IBM BladeCenter T platform

Other required information

Installing the BCP software

Beginning the BCP Installation

Installing the BCP software

Conguration Data Entry

40 BCP Installation on the IBM BladeCenter T platform

Network Based Items

Installing the BCP software

BladeServer slot and NTP clock source

Finishing the BCP Installation

Copyright 2007, Nortel Networks

42 BCP Installation on the IBM BladeCenter T platform

Border Control Point 7200 VLAN tagging

44 Border Control Point 7200 VLAN tagging

Figure 8 BCP 7200 VLAN tagging areas of work

Conguring VLAN tagging using the SMGUI

Conguring VLAN tagging using the SMGUI 45

Figure 9 BCP 7200 SMGUI conguration of Control- and Media-plane VLANs

46 Border Control Point 7200 VLAN tagging Procedure 3 Datalling a VLAN

Conguring VLAN tagging using the SMGUI 47

Procedure job aid