avaya bcp - nn42020-108_01.04_bcp

Nortel Multimedia Communication Server 5100

Border Control PointFundamentals

NN42020-108.

Document status: StandardDocument version: 01.04Document date: 27 April 2007

Copyright © 2007, Nortel NetworksAll Rights Reserved.

Sourced in Canada

The information in this document is subject to change without notice. The statements, configurations, technicaldata, and recommendations in this document are believed to be accurate and reliable, but are presented withoutexpress or implied warranty. Users must take full responsibility for their applications of any products specified in thisdocument. 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.

3

Revision history

April 2007Standard 01.04. This document is up-issued to support MultimediaCommunication Server 5100 Release 4.0. This document addresses CRQ01571232.

March 2007Standard 01.03. This document is up-issued to support MultimediaCommunication Server 5100 Release 4.0. This document addresses CRQ01543719.

January 2007Standard 01.01. This document is issued to support MultimediaCommunication Server 5100 Release 4.0. This document containsinformation previously contained in the following legacy document, nowretired: RTP Media Portal Basics (NN10265-111).

January 2006Standard 4.0. This document is up-issued to support MCS 5100 Release3.5.

November 2005Standard 3.0. This document is up-issued to support MCS 5100 Release3.5.

November 2005Standard 2.0. This document is up-issued to support MCS 5100 Release3.5.

October 2005Standard 1.0. This document is up-issued to support MCS 5100 Release3.5.

Nortel Multimedia Communication Server 5100Border Control Point FundamentalsNN42020-108 01.04 Standard

Release 4.0 27 April 2007Copyright © 2007, Nortel Networks

.

4 Revision history



.

5

Contents

New in this release 9Features 9

BladeCenter T Border Control Point 9BCP/MAS co-residency 9

Other changes 10

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

Regulatory and license information 15Red Hat Software 15Safety information 16

Overview 19How this chapter is organized 19Functional overview 19Network topologies 20Hardware 20Additional references 22Software 22

BCP 7200 22Interfaces and protocols 26

BladeCenter T Evolution 29BladeCenter T overview 29N+1 fault tolerance strategy 30Configuring the BCP 7200 32Software requirements 32BCP 7200 management interface 33Restrictions and limitations for the BCP 7200 33

BCP Installation on the IBM BladeCenter T platform 37How this chapter is organized 37



.

6 Contents

Configuration information 38Other required information 38

Installing the BCP software 38Beginning the BCP Installation 38Finishing the BCP Installation 41

Next steps 42

Border Control Point 7200 VLAN tagging 43Configuring VLAN tagging using the SMGUI 44

Datafilling a VLAN 45Setting VLAN Topology configuration parameters 47

Software requirements or dependencies 49Restrictions and limitations for Border Control Point 7200 VLAN tagging 49

Upgrading the Border Control Point 7000 series 51How this chapter is organized 51Maintenance updates 52How this chapter is organized 52Functional description 52Tools and utilities 52Operations, administration, and management 52Maintenance update tasks 53Service upgrades 57Upgrading to the BladeCenter T 68Firmware upgrades 68

BladeServer firmware upgrade 72BCP 7200 capacity upgrade 73Configuration upgrades 74

Fault management 75How this chapter is organized 75Network fault management 75

Fault tolerance 75BCP 7200 alarms 78Informational and communication logs 79System logs 83

Configuration management 85How this chapter is organized 85Tools and utilities 85Run-Time Service Configuration Parameter Mapping 86Border Control Point 7200 configuration 88How this chapter is organized 88Configuring the BladeCenter T service node 88Configuring the BladeCenter T service data 88

Static Routes Data Structure 95



.

Contents 7

Configuring the BladeCenter T 98BladeCenter T BCP service creation 111

Stand-alone creation 111Service Cluster Instantiation 115

Troubleshooting the IBM BladeCenter hardware 119IBM BladeCenter hardware failure and replacement 119

BladeCenter modules 119Blower modules 121BladeServers (x-blade) 122Expanding the BladeServer (x-blade-combo) 123Replacing the SCSI drive 123BladeCenter chassis 124

Accounting management 125Functional description 125

Performance management 127Viewing operational measurements 128BCP 7200 OMs 128

Security and administration 131How this chapter is organized 131Security overview 131

BCP 7200 component-level security functions 132User administration 133

Managing the Service Cluster 137

BCT configuration worksheet 139

Appendix A Backup and recovery 143How this chapter is organized 143Prerequisites 143Backing up the BCP 144

Error scenarios 151

ProceduresProcedure 1 Beginning the BCP install process 38Procedure 2 Finishing the BCP installation 41Procedure 3 Datafilling a VLAN 46Procedure 4 Setting VLAN Topology configuration parameters 47Procedure 5 Updating a software load for the BCP 7200 component 53Procedure 6 Shutting down the BCP 7200 component 54Procedure 7 Deploying the BCP 7200 component 55Procedure 8 Starting the BCP 7200 56Procedure 9 Performing an MR upgrade on an In-Service Stand-Alone

BladeCenter T BCP service instance 57Procedure 10 Upgrading the BCP Service Cluster 61Procedure 11 Upgrading the Management Module firmware 68Procedure 12 Accessing the Nortel Application Switch 70



.

8 Contents

Procedure 13 Upgrading the Nortel Application Switch firmware 71Procedure 14 Upgrading the BladeServer firmware 72Procedure 15 Obtaining alarm information 76Procedure 16 Clearing an alarm 77Procedure 17 Clearing the RTP101 Alarm (Blade out of service on

initialization) 78Procedure 18 Clearing the RTP102 Alarm (BCP 7200 Out of Service) 78Procedure 19 Clearing the RTP103 Alarm (Portal Port Usage) 78Procedure 20 Clearing the RTP104 Alarm (Host Interface Failure) 79Procedure 21 Creating a static route and adding it to the BCP 7200 96Procedure 22 Configuring the BladeCenter T BCP 7200 99Procedure 23 Creating the service 113Procedure 24 Instantiating the service cluster 117Procedure 25 Removing a module 119Procedure Installing a module 119Procedure 26 Replacing management modules 120Procedure 27 Replacing an existing ESM (I/O module) 120Procedure 28 Replacing power supply modules 121Procedure 29 Removing a blower module 121Procedure 30 Installing a blower module 122Procedure 31 Replacing an existing single-slot blade (or the processor half of

a dual-slotblade) 122Procedure 32 Replacing the SCSI drive 123Procedure 33 Replacing the BladeCenter chassis 124Procedure 34 Setting up the remote tape drive 145Procedure 35 Backing up to a tape drive 146Procedure 36 Restoring the BCP 7200 from tape 148Procedure 37 Fixing an error in the installation of a USB tape drive 152



.

9

New in this release

This chapter describes the changes in Border Control Point Fundamentals(NN42020-108) for Multimedia Communication Server (MCS) 5100 Release4.0.

WARNINGDo not contact Red Hat for technical support on your Nortelversion of the Linux base operating system. If technical support isrequired for the Nortel version of the Linux base operating system,contact Nortel technical support through your regular channels.

FeaturesThis 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 PointMCS 5100 Release 4.0 introduces the IBM* BladeCenter* T (BCT) chassisto support the Border Control Point (BCP; formerly known as the RealtimeTransport Protocol [RTP] Media Portal). Introduced in conjunction withthe BCT for MAS feature, this feature uses the same hardware as theMedia Application Server (MAS), and together these features work withthe BCP/MAS co-residency feature.

The BladeCenter T RTP Media Portal feature encompasses the introductionof the new hardware, the evolution of the BCP software to execute on thehardware, and the introduction of the N+1 (N active and 1 standby) faulttolerance strategy.

BCP/MAS co-residencyWith this feature, the BCP and MAS applications can co-reside in the sameIBM BladeCenter T chassis. For example, you can use the same chassis forBCP, 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) inthe chassis. Co-residency reduces hardware costs and provides a flexiblegrowth strategy for existing systems.

BCP OM enhancementsThis feature provides Operational Measurement (OM) enhancements for theBCP. These enhancements introduce new OM groups (MediaPortalInstanceand Ports) and add new OM registers to the MediaPortal OM group.

Other changesSee the following sections for information about changes that are notfeature-related:

• The BCP is enhanced to provide IEEE 802.1Q VLAN taggingfunctionality. VLAN tagging facilitates easier integration into theCommunication Server 1000 (CS1000) solution and adds extra flexibilitywhen introducing the BCP 7200 into complex topologies. You configureand utilize IEEE 802.1Q capabilities through the System ManagementConsole (SMC). The SMC is enhanced to enable you to specify VLANmembership for control- and media-plane points of presence. The StaticRoute datafill is also changed to permit association of static routes toVLANs. For information about this feature, see Border Control Point7200 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 theBladeCenter-T" (page 68).

• "Fault management" (page 75) contains new information aboutBladeCenter T and BCP 7200 faults and updated fault management.

• "Configuration management" (page 85) contains new information aboutrun-time service configuration parameter mapping for the BladeCenterT (BCT) in a table.

• The section "Border Control Point 7200 configuration" (page 88)describes BCP 7200 configuration.

• For information about BCT troubleshooting, see "IBM BladeCenterhardware failure and replacement" (page 119).

• "Accounting management" (page 125) contains detailed informationabout changes to accounting functionality.

• "Performance management" (page 127) contains detailed informationabout performance management and a new Operational Measurement(OM) Group HALayer for the BCT.



.

Other changes 11

• "Security and administration" (page 131) contains a detailed discussionof new security provided with the BladeCenter T and BCP 7200.

• BIOS configuration of the CPV5370 host card contains a change tostep 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 siteThe content of this documentation was current at the time the product wasreleased. To check for updates to the latest documentation for MultimediaCommunication Server (MCS) 5100, go to www.nortel.com and navigate tothe Technical Documentation page for MCS 5100.

Getting help from the Nortel web siteThe best way to get technical support for Nortel products is from the NortelTechnical Support web site:

www.nortel.com/support

This site provides access to software, documentation, bulletins, and tools toaddress 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 Basefor answers to technical issues

• arrange for automatic notification of new software and documentationfor Nortel equipment

• open and manage technical support cases

Getting help over the phone from a Nortel Solutions CenterIf you do not find the information you require on the Nortel Technical SupportWeb site, and you have a Nortel support contract, you can also get helpover 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 telephonenumber for your region:

www.nortel.com/callus



.

http://www.avaya.com

http://www.avaya.com/support

http://www.avaya.com/callus

14 How to get help

Getting help from a specialist by using an Express Routing CodeTo access some Nortel Technical Solutions Centers, you can use an ExpressRouting Code (ERC) to quickly route your call to a specialist in your Nortelproduct or service. To locate the ERC for your product or service, go to:

www.nortel.com/erc

Getting help through a Nortel distributor or resellerIf you purchased a service contract for your Nortel product from a distributoror authorized reseller, contact the technical support staff for that distributoror reseller.



.

http://www.avaya.com/erc

15

Regulatory and license information

This chapter contains regulatory and license information.


Red Hat SoftwarePassthrough End User License Agreement

This section governs the use of the Red Hat Software and any updatesto the Red Hat Software, regardless of the delivery mechanism and isgoverned by the laws of the state of New York in the U.S.A. The Red HatSoftware is a collective work under U.S. Copyright Law. Subject to thefollowing terms, Red Hat, Inc. ("Red Hat") grants to the user ("Customer") alicense to this collective work pursuant to the GNU General Public License.Red Hat Enterprise Linux (the "Red Hat Software") is a modular operatingsystem consisting of hundreds of software components. The end userlicense agreement for each component is located in the component’ssource code. With the exception of certain image files identified below, thelicense terms for the components permit Customer to copy, modify, andredistribute the component, in both source code and binary code forms.This agreement does not limit Customer’s rights under, or grant Customerrights that supersede, the license terms of any particular component. TheRed Hat Software and each of its components, including the source code,documentation, appearance, structure and organization are owned by RedHat and others and are protected under copyright and other laws. Title tothe Red Hat Software and any component, or to any copy, modification,or merged portion shall remain with the aforementioned, subject to theapplicable license. The "Red Hat" trademark and the "Shadowman" logoare registered trademarks of Red Hat in the U.S. and other countries. Thisagreement does not permit Customer to distribute the Red Hat Softwareusing Red Hat’s trademarks. If Customer makes a commercial redistributionof 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 anyfiles identified as "REDHAT-LOGOS" and "anaconda-images" to removeall 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 Department’s 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, Sudanand Syria); (c) will not export, re-export, or transfer the Software to anyprohibited destination, entity, or individual without the necessary exportlicense(s) or authorizations(s) from the U.S. Government; (d) will not useor transfer the Red Hat Software for use in any sensitive nuclear, chemicalor biological weapons, or missile technology end-uses unless authorizedby the U.S. Government by regulation or specific license; (e) understandsand agrees that if it is in the United States and exports or transfers theSoftware to eligible end users, it will, as required by EAR Section 740.17(e),submit semi-annual reports to the Commerce Department’s Bureau ofIndustry & Security (BIS), which include the name and address (includingcountry) of each transferee; and (f) understands that countries other thanthe United States may restrict the import, use, or export of encryptionproducts and that it shall be solely responsible for compliance with anysuch import, use, or export restrictions. Red Hat may distribute third partysoftware programs with the Red Hat Software that are not part of the RedHat Software. These third party programs are subject to their own licenseterms. The license terms either accompany the programs or can be viewedat http://www.redhat.com/licenses/. If Customer does not agree to abideby the applicable license terms for such programs, then Customer maynot install them. If Customer wishes to install the programs on more thanone system or transfer the programs to another party, then Customer mustcontact the licensor of the programs. If any provision of this agreementis held to be unenforceable, that shall not affect the enforceability of theremaining provisions.

Copyright © 2003 Red Hat, Inc. All rights reserved.

"Red Hat" and the Red Hat "Shadowman" logo are registered trademarksof Red Hat, Inc."Linux" is a registered trademark of Linus Torvalds.All other trademarks are the property of their respective owners.

Safety informationThis section contains important safety information.



.

http://www.redhat.com/licenses/

Safety information 17



.

18 Regulatory and license information



.

19

Overview


How this chapter is organizedThis 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 overviewThe Border Control Point (BCP 7200 series) component addresses mediaplane-specific issues with advanced service delivery, Internet addressingefficiencies, and system security.

The primary function of the BCP series is to extend the reach of multimediaservices so that they are accessible to obscured endpoints, devices residingbehind a firewall, or a Network Address Translation (NAT) or NetworkAddress Port Translation (NAPT) device. The BCP 7000 series alsoprovides IP address and port pair mapping for internal and external networkcomponents as well as media anchoring and media pivot abilities. In thisway, the BCP 7000 series functions as a media NAPT point that can shieldnetwork components from external exposure.



.

20 Overview

The BCP 7000 series operates under the control of a call server using theMedia Portal Control Protocol (MPCP). The call server instructs the BCPwhen to open or close media pinholes and specifies which media canfunction.

The IBM BladeCenter T (BCT) is the BCP platform for the BCP 7200 thatmeets the needs of a maturing Voice over Internet Protocol (VoIP) market.The BCT provides improved:

• density (more media flows for each unit of rack space)

• media bandwidth

• supportability

• reliability strategy

Network topologiesThe BCP 7000 series can be deployed in a single- or dual-networkconfiguration. For dual networks, the BCP 7000 series enables elements inthe protected network to safely communicate with elements in the managedIP access network.

HardwareThe BCP 7200 is available on the IBM BladeCenter T.

Figure 1BladeCenter 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 forNetwork Equipment Building Systems (NEBS) telecommunications networkapplications and other applications requiring additional physical robustness.

The BladeCenter T unit uses BladeServers, switches, and other componentsthat are common to the IBM BladeCenter* product line. This commoncomponent strategy makes the BladeCenter T unit ideal for applications intelecommunications networks that need high levels of computing powerand access to common off-the-shelf middleware packages that are used inIT data centers.



.

Hardware 21

The BladeCenter T unit supports up to eight BladeServers, making itideally suited for networking environments that require a large number ofhigh-performance servers in a small space.

The BladeCenter T unit provides common resources that are shared bythe BladeServers, such as power, cooling, system management, networkconnections, backplane, and input/output (CD-ROM drive and connectorsfor USB, keyboard, video, mouse, and network interfaces).

The following is a list of parts for the IBM BladeCenter T. For detailedinformation about the hardware, see http://www.ibm.com and also see thefollowing figure, Figure 2 "IBM BladeCenter T exploded chassis" (page 21).

• Chassis (AC-powered chassis: Type 8730; DC-powered chassis: Type8720)

• power modules (AC or DC power)

• media tray

• management modules

• blower modules

• KVM module

• LAN module

• IO modules

• BladeServers

Figure 2IBM BladeCenter T exploded chassis



.

http://www.ibm.com

22 Overview

Additional referencesFor information about third-party equipment, see the following references:

• IBM e-server BladeCenter T Types 8720 and 8730 Installation andUser’s 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 User’s Guide

• Nortel Layer 2/3 GbE Switch Module for IBM e-server BladeCenter TInstallation Guide

Software

CAUTIONOnly Nortel-certified software may be installed on the IBMBladeCenter T. Do not install software updates obtained directlyfrom IBM.

The BCP 7000 Series is primarily a software entity comprising logicalsubcomponents that participate in many planes of operation. Thedistribution of these logical subcomponents depends on the underlyinghardware platform (BladeCenter T). This distribution affects the point ofpresence of the BCP in the service planes and the complexity of theimplementation.

BCP 7200The BCP 7200 consolidates all logical subcomponents onto a single pieceof hardware, the BladeServer. As a result, the BCP 7200 can provide N+1fault tolerance. The software rearchitecture required by the BladeCenter TBCP abstracts the functionality provided by the BCP from the underlyingplatform, establishing the BCP as a service that is independent of a fixedrelationship with its supporting hardware. Further, the N+1 fault toleranceframework adds another dimension to the BCP.

The BladeCenter T BCP operates as either a collection of independentservice instances (standalone) or as an N+1 fault-tolerant servicecluster (clustered). Both standalone and clustered configurations of theBladeCenter T BCP are configured as service clusters; however, thestandalone operation is configured as a 1+0 (1 active instance, and no



.

Software 23

standby instances) service cluster. The difference between the standaloneand clustered configurations is their run-time characteristics and reactionsto faults.

When configured as a collection of standalone service instances, a singleBladeCenter T can support the execution of up to eight independentnonredundant instances of the BCP Service. For more information, seeFigure 3 "Stand-Alone BCP service instances (chassis view)" (page 23).

Figure 3Stand-Alone BCP service instances (chassis view)

When configured as a redundant N+1 fault-tolerant service cluster, a singleBladeCenter T supports the execution of up to seven active instances of theBCP Service and one hot standby instance that is ready to assume theactive sessions for any of the active instances. For more information, see theFigure 4 "N+1 fault-tolerant BCP Service Cluster (chassis view)" (page 24).



.

24 Overview

Figure 4N+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 necessarilyhave a fixed association with the underlying hardware. This layeringof service and service nodes enables service instances to float overtheir associated service nodes, which enables the service to surviveservice node (hardware) failures. This abstraction is represented inthe System Management Console using the configuration entity MediaPortal Cluster that is associated with underlying hardware through itsrelationship with the (changed) RTP Portals entity.

• an extension to the RTP Portals Network Element (the RTP Portalsdata structure includes the MPCluster name field ) that enables servicenodes (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 configure the BladeCenter T BCP as a standalone serviceinstance (in other words, a 1+0 service cluster) using data structuresinside the Media Portal cluster entity.

• the ability to configure the BladeCenter T BCP as an N+1 fault-tolerantservice cluster (where N=7) using data structures inside the MediaPortal Cluster entity.



.

Software 25

• the ability to define and configure static routes for the BladeCenter TBCP from the Management Console using the External Nodes, SubnetMasks, and Static Routes entities.

• the ability to transitively manage the BladeCenter T BCP service clusteras a set of distinct network elements. (Cluster-level managementcapabilities do not exist. The Cluster is managed through thecoordinated management of the individual service nodes.)

Figure 5 "System Management Console: affected data structures" (page25) shows an overview of the System Management Console that supportsthe BladeCenter T.

Figure 5System Management Console: affected data structures

The major difference between the two service node variants is the locationof the service-level data (see Figure 6 "Configuration data structures andrelationship to service nodes" (page 26)). For the BladeCenter T, the servicenode is represented by the RTP Portal NE while the service data resides inthe Media Portal Cluster entity. A loose coupling of service data to service



.

26 Overview

nodes is accomplished through the addition of the MPCluster name fieldto the RTP Portal NE, which associates the referenced service data withthe service node. In this way, the RTP Portal NEs represent the physicalplatform, and the BCP service becomes a logical abstraction that is definedin the Media Portal Cluster entity. This enables the BCP service instancesto dynamically establish residence on the associated service nodes and tofloat among the associated RTP Portal NEs as failures occur.

Figure 6Configuration data structures and relationship to service nodes

Interfaces and protocolsWhile in service, the BCP communicates with other components in thesystem using the following protocols:

• MPCP—Media Portal Control Protocol controls messages between theSession Manager and the BCP. MPCP messages control the making,modification, and breaking of media session connections.



.

Interfaces and protocols 27

• RTP—Real-time Transport Protocol transports real-time media streams(for example, audio and video) across a packet network.

• RTCP—Real-time Transport Control Protocol provides a meansof sharing session data (for example, performance data) betweenendpoints. Real-time Transport Control Protocol (RTCP) provides anexchange of information pertaining to the quality of an associated mediasession (for example, packet counts, packets lost, latency, jitter).

• UDP—User Datagram Protocol transports data-based media streams(for example, file transfer).

• TCP—Transmission Control Protocol communicates configuration,performance data, logs, and alarms (OAM data) between the BCP 7200and the management system.



.

28 Overview



.

29

BladeCenter T Evolution

The evolution to the second generation BCP encompasses the followingactivities:

• "BladeCenter-T overview" (page 29)

• "N+1 fault tolerance strategy" (page 30)

• "Configuring 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 overviewThe BladeCenter T-based BCP 7200 exists in the control-plane (for MPCPmessaging), the management-plane (for OAM), and the media-plane (foraccess to media streams). The BladeCenter T BCP 7200 appears (from amacro-level) to be the same as established legacy deployments. However,the BladeCenter T BCP 7200 does introduce some change as to how it ispresented in each of the service-planes at a subatomic level (not visible tothe outside world) and introduces a service-plane used for inter-clustercommunications:

• The BladeCenter T BCP abstracts the BCP Service from the underlyingservice node platform. The BladeCenter T BCP 7200 consists of aBCP service, which resides in the Control-plane and the Media-Plane,and a separate BladeCenter T platform, which resides in theManagement-plane. With this architectural change, the BladeCenter TBCP has separate and distinct points of presence in the Control-plane(the logical Control IP address), the Management-plane (the physicalIP address of the BladeServer), and the Media-plane (the logical IPaddresses associated with Net1 and Net2).

• The introduction of N+1 fault tolerance with the BladeCenter T BCPcreates a service-plane (orthogonal to all others) to support IntraClusterService Communications as part of the N+1 fault-tolerance framework.This service-plane is called the Peering-plane. All Service Instances thatare 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 uniquelyidentifies the intracluster communication channel.

By retaining presence in the service-planes and making internalizedchanges that are not visible to the outside world, the BladeCenter T BCPmaintains functional and operational equivalence with legacy configurationsfrom the perspective of other elements residing within the Service-planes:

• The BladeCenter T BCP appears identical from the perspective of theMCS Management Server as viewed in the Management-plane. Thisappearance is accomplished transparently as the BladeCenter T BCPcontinues to use the preexisting RTP Portals Network Element as itspoint of attachment to the Management-plane.

• The BladeCenter T BCP is deployed using the RTP Portals NetworkElement.

• The BladeCenter T BCP conveys telemetry (Logs, Alarms, andOperational Measurements) through the RTP Portals Network Element.

• The BladeCenter T BCP is managed (Start, Stop, Kill) through the RTPPortals Network Element.

• The BladeCenter T BCP appears identical when viewed from theperspective of the controlling Call Server (in the Control-plane) becausecontrol sessions are initiated and maintained consistently across bothplatforms. The BladeCenter T BCP also supports the same version ofthe Media Portal Control Protocol (MPCP) that is supported by legacysystems.

• The BladeCenter T BCP maintains support for both single- anddual-network configurations and provides the same media-layerfunctions as the legacy CPX8216-T systems. In this way, theBladeCenter T BCP also appears identical in terms of Media-planecapabilities.

N+1 fault tolerance strategyThe BCP 7200 reliability strategy treats the BCP 7200 as a pooled resource.Each BCP 7200 is configured to advertise its availability to provide serviceto a set of call servers. The call servers place each available BCP 7200 intoa media resource pool that is used to serve up available media resourcesduring call processing.

In this manner, traffic is distributed over many BCP 7200s, which lessensthe impact of a failure. While lessening the impact of most failure conditions,this strategy does not preserve media sessions that exist on a piece offailed hardware. As a result, failure scenarios for the original BCP 7200can result in the loss of active calls.



.

N+1 fault tolerance strategy 31

Simplification of the software architecture affords an opportunity to takea quantum leap forward in terms of the fault tolerance attributes of theBCP 7000 series when it executes on the IBM BladeCenter T platform.The consolidation of both Host and Media Blade functions into a singleentity greatly reduces the complexity of providing the N+1 fault tolerancecapabilities delivered by this feature.

The N+1 fault-tolerant BCP 7200 is achieved through the creation offault-tolerant service clusters that define a set of BCP 7200 instances (the"N" logical service instances) and that identify the target servers that host theinstances ("N" servers to run the active service instances and an additionalserver to run a standby service instance). In this way, a fault-tolerant BCP7200 can have active media sessions survive the catastrophic failure of asingle instance of the service by having a standby instance that is ready andable 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 reliablemessaging framework that ensures connectivity between cluster members.The operating context of the cluster members is established throughan election protocol that runs over the reliable messaging framework todynamically determine which servers are running active instances of theBCP 7200 and which server is running the standby instance.

This operating context is maintained through use of a heartbeat mechanismthat continuously validates the state of members in the cluster. After thecluster is formed, all state data for each active media stream (on each activeinstance of the BCP 7200 in the cluster) is checkpointed to the standby BCP7200 instance. In this way, the standby instance remains synchronized withall active instances and is thereby ready to take over processing of thesessions for any of those instances if a failure occurs.

The N+1 takeover process is transparent to the endpoints that areoriginating and terminating the media streams relayed through the failedinstance. The standby instance begins receiving and relaying those samemedia streams as soon as the failure is detected and takeover is affected.

Initially, N+1 fault tolerance capabilities are restricted to the confinesof a single IBM BladeCenter T chassis. This enables configurationof 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 ServiceCluster (example 5 active +1 standby configuration)" (page 32).



.


Figure 7BCP 7200 N+1 fault-tolerant Service Cluster (example 5 active +1 standby configuration)

Configuring the BCP 7200Hardware configuration and network connectivity occur during installationand commissioning, as well as during maintenance and repair. See theappropriate methods and procedures documentation. Component softwareconfiguration for the BCP 7200 introduces an additional layer of abstraction(MPCluster) that changes the cAfterptual view so that the BCP is now aservice that floats over the associated platforms.

For software configuration, see "Configuration management" (page 85).

Software requirementsThe BladeCenter T BCP requires Red Hat Linux ES 3 Linux OperatingSystem. Also, the dependency on the supporting hardware implies adependency 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 theBladeServer BIOS. The BCP 7200 also has firmware dependencies onmaintenance diagnostics and Ethernet drivers.

Table 1BCP 7200 external software dependencies

External dependency Description

Red Hat Linux ES 3 the Operating System installed on the BladeServershosting the BCP Service in the IBM BladeCenter T chassis

IBM BladeCenter TManagement Module Firmware

the firmware that implements the chassis administrativefunctions

Nortel Application Switch ESMSoftware Image

the network switching software that providesinterconnectivity to the Service Networks

BladeServer BIOS the BIOS resident in the BladeServer

BCP 7200 management interfaceThe Management Server and the System Management Console provide agraphical interface from which to configure and manage the BladeCenter TBCP. The System Management Console provides access to the followingstructures affected by this feature:

• The Network Data and Mtc data structures provide a ready means ofconfiguring subnet extent (Subnet Masks), and static routes (ExternalNodes and Static Routes).

• The Media Portals top-level Network Elements folder contains entitiesassociated with the BCP.

• The Media Portal Cluster data structure represents the logicalabstraction of the BCP as a service.

• The MP Cluster field introduced into the existing RTP Portal NE InstanceData (RTP Portals) enables the association of service nodes to serviceclusters.

Restrictions and limitations for the BCP 7200The following restrictions and limitations exist on the BladeCenter T BCP:

• The BladeCenter T BCP does not support LiveUpdate functionality. Anyconfiguration data changes related to data that can affect the BCP aredetected and alarmed by all in-service BCPs that can potentially beimpacted by the change. This alarm can be acknowledged (to mute itfrom the System Management Console), but the root condition persistsuntil the afflicted BCPs are cycled back into service (so that they canpick up the latest configuration data from the database).



.


• BladeCenter T BCP configurations are constrained so that they canonly provide service to a maximum of twenty Call Servers. This is themaximum number of Session Managers only, Gateway Controllers only,or a combination of both Session Managers and Gateway Controllersthat are configured against a BCP.

• Due to high-layer data constraints required by the MCS solution tomaintain data consistency for Media Portal Groups in the ProvisioningGUI, it is not possible to change the MPCluster name associated with aRTP Portal NE. After such an association is made, the only way to alterit is to delete and readd the RTP Portal NE into the system.

• Each BladeCenter T service node (BladeServer) only supports twoEthernet network interface cards (NIC) that must be configured as anactive/standby NIC Team.

• The NIC Team configured on the BladeCenter T service node(BladeServer) is not configured for Auto-Fallback and consequently, apreferred NIC does not exist.

• Each BladeCenter T chassis must have two Management Modules toprovide fault-tolerant access to platform administration and managementfunctions.

• Each BladeCenter T chassis must have two Nortel Application Switches(of the same type: copper or fiber-optic) to provide fault-tolerant accessto the Service Networks.

• The BladeCenter T BCP only supports Nortel Application Switches in IOModule Bays one and two.

• The Nortel Application Switch (in both copper and fiber-optic variants) isthe only IO Module supported for the BladeCenter T BCP.

• The BladeCenter T BCP is configured so that the Nortel ApplicationSwitches are only manageable through the Management Module’sexternal interface into the Management Network (managementthrough the Nortel Application Switch external ports is disabled in theManagement Module).

• While it is technically possible to upgrade the Nortel Application Switchfirmware through the external ports of the Nortel Application Switch, thisprocedure is not supported for the BladeCenter T BCP, since thoseexternal ports are not enabled for management activity.

• The IBM e-server BladeCenter HS20 (Type 8843L1U) BladeServer isthe only supported processing element for the BladeCenter T BCP.

• Each BladeCenter T chassis must have four Power Modules to providefault-tolerant power to the entire chassis.

• Each BladeCenter T chassis must have four Blower Modules to providesufficient cooling for the chassis.



.

Restrictions and limitations for the BCP 7200 35

• The BladeCenter T Stand-Alone BCP service instance is really a1+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, andone standby Service Instance) is the smallest-sized fault-tolerantconfiguration.

• The 7+1 BCP Service Cluster (seven active Service Instances, and onestandby Service Instance) is the largest-sized fault-tolerant configuration.

• The BCP Service Cluster cannot span the BladeCenter T chassis.

• The fault-tolerant BCP Service Cluster can survive a single catastrophicfault at which time the Service Cluster commences operating infailure-mode and the standby Service Instance assumes the identityof the active Service Instance impacted by the catastrophe. Thefault-tolerant BCP Service Cluster cannot survive subsequentcatastrophic faults while operating in failure-mode (since a standbyService Instance no longer exists).

• The BladeCenter T BCP Service can only be managed transitivelythrough management of the associated RTP Portal NEs.

• The BladeCenter T Nortel Application Switches are not configured forAuto-Fallback functionality, so a preferred Nortel Application Switchdoes not exist.

• The Static Routes data structures are applicable to the BladeCenterT BCP.

• The RTP Portals Network Element contains a configuration parameterMPCluster name that is used to associate the RTP Portal NE with aMedia Portal Cluster. For BladeCenter T sites (both standalone andclustered), this parameter must reference a valid Media Portal Clusterdata structure.

• The BladeCenter T BCP continues to use preexisting data structuresto convey non-service specific configuration information (for example,the RTP Portals Network Element for the conveyance of engineeringparameters).



.




.

37

BCP Installation on the IBMBladeCenter T platform

How this chapter is organizedThis chapter describes the installation of a Border Control Point on theIBM BladeCenter T Platform.

The chapter is organized as follows:

• "Configuration information" (page 38)

• "Installing the BCP software" (page 38)

The RTP Media Portal on the IBM BladeCenter T (BCT) platform providessignificant capacity and robustness. Each of the eight BladeServers in thechassis is an individual Border Control Point (BCP). Each BCP can be usedindependently 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 ofthe remaining N BladeServers fails.

The installation and configuration process must be repeated for eachBladeServer in the chassis.

Installation and configuration on the BCT platform involves the followingsteps:

• assembly of the hardware

• configuration of the BladeServer BIOS

• installation of the software on the BladeServer

Installing the RTP Portal software requires only a single disc. The completebase system can be installed in approximately 15 minutes or less.



.

38 BCP Installation on the IBM BladeCenter T platform

Configuration informationTo configure the BCP successfully, you must capture configurationinformation accurately. The information that is required to provision theBCP must be collected prior to installation. For more information aboutcollecting this data, see Table 8 "Information Required for Installation andCommissioning on the BCT platform" (page 139).

Other required informationThe following information is required to fully configure a BCP:

• a root password for the host

• a password for the Nortel user

• a password for the sysadmin user

Installing the BCP softwareInstalling the BCP from a CD is a simple process. The machine is bootedfrom CD, the information in the table is requested by the installationsoftware, and then the software is copied to the hard drive and the machineis configured.

Beginning the BCP InstallationThe BCP uses a standard RedHat Linux distribution. The followingprocedure describes the beginning of the BCP installation process.

Procedure 1Beginning the BCP install process

Step Action

1 Establish a terminal session to the host CPU through the terminalserver.

2 The system boots from the installation CD.

The initial welcome screen appears.

There are no options to enter at the boot: prompt. Press Enter tobegin the install.

3 The installation software loads and checks for existing disk partitions.You are notified of the results of the partition check, and if partitionsare created and formatted, you are prompted to press Enter toproceed with the formatting.

—End—



.

Installing the BCP software 39

The next phase of the BCP installation is configuration data entry. If you areinstalling the BCP for the first time, you must enter all the required data.

Configuration Data EntryAs you enter configuration data, keep in mind that a mistake can be fixed. Ifyou realize that you have entered data incorrectly, continue with the dataentry process. At each major step of data entry, the installer prompts you toverify that the data is correct. If there is a mistake, answer N and reenter thedata for that step. Many prompts for configuration data items have a defaultanswer. If available, the default answer appears to the right of the promptand is enclosed in square brackets. To accept the default value, press Enter.

First-time installWhen you install the BCP for the first time, you can enter configuration datafrom the system console, load a configuration file from a remote server, orrestore configuration data from an existing backup. You are presented witha Configuration Data Selection screen with the following options:

• Manual Data Entry—

When you enter configuration data manually, the installer prompts youfor each configuration setting. Use the information you collected intheInformation Required for Installation and Commissioning on the BCTplatform table to answer the questions.

• Using a Remote Configuration File—

With this option, you can use a configuration file that is stored on aremote server. For example, if you are installing several portals, you cancreate a basic installation file and store it on a remote server. This filecan then be used as a starting point for each portal you install.

The installer prompts you to enter the IP address, gateway, and netmaskfor the portal you are installing. Next, you enter the remote FTP serverIP address and your user name and logon information. The pathnameof the directory containing the configuration file is required at this time.The pathname is relative to the home directory of the user name thatyou specify for the FTP logon. The installer will contact the remote FTPserver and obtain a directory listing, which is displayed on the screenas follows:

— MCPPostInstall.log

— PreInstall.log

— BackupInfo.file

— lost+found

— portal.cfg

— post-install.log



.


— time zones

— Cancel remote configuration file selection

When you use the remote configuration option, choose portal.cfg(option number five). The installer obtains the selected file and readsthe configuration from that file, and then prompts you to change theconfiguration data.

• Restoring from a Prior Backup—For more information, see "Restore"(page 148).

Network Based ItemsThe first phase of data configuration involves the following network-baseditems:

• Application type—A read-only value that is configured automatically bythe installer and cannot be changed. It describes the type of applicationbeing installed.

• Platform type—A read-only value that is configured automatically by theinstaller and cannot be changed. This value is configured according tothe hardware platform that you configure.

• Hostname—The name you give to the BCP.

• Machine Logical IP—The IP address assigned to the BCP.

• Default Gateway—The default gateway router assigned to the BCP hostcard.

• Netmask—The network mask for the BCP host card.

• Timezone—The timezone where the BCP is physically located.

• Host IP failover active—The true or false value that controls the hostIP failover service. If the service is active, the host card uses networkinterfaces in an active or standby configuration.

After you configure the first phase of data configuration, the installerpresents the validation screen. If the information is correct, press Enter toaccept the values displayed for each item (if there are any mistakes, pressN to reenter phase one data).

After the items in phase one have been successfully configured, phase twoof data configuration begins.



.

Installing the BCP software 41

BladeServer slot and NTP clock sourceThe second phase of data configuration involves the following media cardrelated information (again, each item is presented with a default value ifone is available):

• BladeServer Slot—This is the BladeServer slot number (it must bea number between one and eight). Every BladeServer in the samechassis must have a unique slot number.

• NTP Clock Source—This is the IP address of the NTP server that theRTP Media Portal obtains clock synchronization. There can be zeroor more configured NTP clock sources, but only one is displayed atthis time.

If the information is correct, press Enter to accept the values displayed foreach item (if there are any mistakes, press N to reenter phase one data).

Finishing the BCP InstallationAfter you finish the second phase of data configuration, you perform the finalsteps to finish the BCP installation.

Procedure 2Finishing the BCP installation

Step Action

1 From the Date and Time Configuration screen, press Enter if thetime is correct. Otherwise, press N to change the time.

2 Next, the installer prompts you for the root, nortel, and sysadminpasswords. These passwords must be at least eight characters inlength.

The installer performs a basic validation of passwords.

3 The script begins installing the individual software packages.

A progress indicator appears on screen.

This part of the installation takes approximately 10 minutes tocomplete.

4 Next, the installer configures the system for specific BCPrequirements.

This step in the process takes approximately 5-10 minutes.

5 The system reboots. Remove the CD-ROM from the drive when itis ejected.

6 As the system is powering on, hold down the F2 key to enter theBIOS 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. Thelogon prompt appears and the BCP is ready for software deployment.

—End—

Next stepsWhen the installation is complete, the next step in deploying the BorderControl Point is to configure the Media Portal using the MCS ManagementConsole. See "Border Control Point 7200 configuration" (page 88).



.

43

Border Control Point 7200 VLANtagging

ATTENTIONThis 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 easierintegration into the CS2000 solution and adds an extra dimension offlexibility when introducing the BCP 7200 into complex topologies.

Virtual LANs (VLANs) are intended as a way to segment networks atLayer-2 to increase network flexibility without changing the physicalnetwork topology. A side benefit of this segmentation is the extra securityassociated with the isolation provided to each of the segments throughlogical separation. When a device is configured to participate in a VLAN,it becomes a member of that broadcast domain.

Layer-2 segmentation is accomplished through the introduction of additionalheader information into the Layer-2 Ethernet Frame that associates theframe with a specific VLAN. The introduction of this additional information inthe Ethernet Frame requires that network components (network interfacecards) be VLAN-aware so that they can properly process such frames.The BCP 7200 platform comprises hard- and soft-subcomponents that areVLAN-aware. You can use VLAN tagging to tap into these latent abilities.

Providing IEEE 802.1Q VLAN tagging support on the BCP 7200 involvesthe following distinct areas of work:

• physical interconnect of the BCP 7200 to the Service Networks.

• configuration of the Ethernet Switching Module (ESM) subcomponent ofthe BCP 7200 for proper conveyance of VLAN traffic into the ServiceNetworks.

• configuration of the IEEE 802.1Q VLAN tagging capabilities in theOperating 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 underlyingOperating System with the BCP 7200 Media Portal ComponentSoftware.

Figure 8BCP 7200 VLAN tagging areas of work

Configuring VLAN tagging using the SMGUIThe System Management Graphical User Interface (SMGUI) accommodatesconfiguration of the BCP 7200 RTP Media Portal service for operation inVLAN-tagged Service Network topologies.

• Service Network VLAN Topology:

— The VLAN configuration parameter in the Network Data & Mtc folderpermits specification of Service Network VLAN information.

— The VLAN Topology configuration parameter in the Media PortalCluster folder permits association of an RTP Media Portal ServiceInstance network spaces to specific VLANs.

• Static Route VLAN Assignments:



.

Configuring VLAN tagging using the SMGUI 45

— The Static Routes configuration parameter in the Media PortalCluster data has a data structure that permits granular assignmentof Static Routes to specific VLANs.

The introduction of VLAN information into the system enables RTP MediaPortal Service Instances hosted on the BCP 7200 to be configured withpresence in separate VLANs that represent:

• a distinct network space for Control-plane traffic

• two separate network spaces for Media-plane traffic (one for Net1media, and the other for Net2 media)

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

Datafilling a VLANEvery VLAN in the Service Network that is to be extended to the BCP 7200must be datafilled into the system. Network VLAN Topology is entered intothe system using the VLAN configuration parameter in the Network Data& Mtc folder.



.


Procedure 3Datafilling a VLAN

Step Action

1 Open the System Management Console.

2 In the navigation pane (left-side), click the Network Data & Mtc.folder to view its contents.

3 In the Network Data & Mtc folder, click the Media Portal Datafolder to view its contents.

4 In the Media Portal Data folder, click the VLANs configurationparameter.

The VLANs configuration window appears.

5 In the VLANs configuration window, click the + button.

The Add VLANs window appears.

6 In the VLAN Name field, specify a unique name in the system thatrepresents this particular data element.

7 In the VLAN ID field, specify the VLAN Identifier (VID) that definesthis VLAN in the Service Network.

8 Click Apply.

—End—



.

Configuring VLAN tagging using the SMGUI 47

Procedure job aidFigure 10SMGUI Configuration of Service Network VLANs

Setting VLAN Topology configuration parametersAfter all of the required Service Network VLANs are defined in the system,you can associate them with any combination of BCP 7200 RTP MediaPortal Service Instances using the VLAN Topology configuration parameterspresent in the Media Portal Cluster data.

Procedure 4Setting VLAN Topology configuration parameters

Step Action

1 Open the System Management Console.

2 In the navigation pane (left-side), click the Network Elements folderto view its contents.

3 In the Network Elements folder, click the Media Portals folder andclick it to view its contents.

4 In the Media Portals folder, click the Media Portal Cluster folderto view all BCP 7200 RTP Media Portal Service Clusters datafilledin the system.

5 In the Media Portal Cluster folder, open a Media Portal Clusterinstance folder to view the available configuration parameters.Locate the VLAN Topology configuration parameter.



.


6 Click the VLAN Topology configuration parameter. The VLANTopology window for the current Media Portal Cluster appears inthe right pane work area.

7 In the Control VLAN field, associate a Service Network VLAN tothe Control IP address.

8 In the Net1 Media VLAN field, associate a Service Network VLANto the Net1 Media IP address.

9 In the Net2 Media VLAN field, associate a Service Network VLANto the Net2 Media IP address.

10 Click Apply .

11 Cycle the BCP 7200 (either through Stop+Start, Kill+Start, orRestart) to enable the BCP 7200 to pick up configuration changes.

—End—

Procedure job aidFigure 11SMGUI 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 dependenciesThe following software changes are not required by this feature but occur aspart of the normal course of product development:

• Upgrade to JVM 1.4.2_09 (moves the RTP Media Portal Componentsoftware onto the version of the Java Virtual Machine used across otherproduct components).

• Upgrade to ESM firmware (up-version to collect bug-fixes and to gainaccess to enhancements in the Layer-2 Trunk Failover mechanism thatprovide configurable control over the failover-trigger).

• Upgrade to IBM BladeCenter T (BCT) subcomponent firmware(up-version to collect bug-fixes).

Restrictions and limitations for Border Control Point 7200 VLANtagging

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 servicetraffic on the BCP 7200. Tagging of the out-of-band platformmanagement traffic (traversing the Management Modules in the chassis)is not permitted.

• Since VLAN tagging fundamentally changes the format of framestransmitted on a tagged port, carefully planned network designs areneeded to prevent tagged frames from being transmitted to devicesthat do not support IEEE 802.1Q VLAN tags, or devices where taggingis not enabled.

• The BCP 7200 does not support live update of configuration changes,so configuration data does not get picked up in run-time until the BCP7200 is cycled (that is, Stop + Start, Kill + Start, or Restart).

• Configuration parameter default values (<none>) target operation inuntagged topologies.

• Ethernet Switching Module (ESM) restrictions and limitations withrespect to IEEE 802.1Q VLAN tagging support. See the latest ESMdocumentation 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 isconfigured so that management ports are configured to the defaultVLAN 4095.

— The ESM can support a maximum of three separate Layer-2 LinkAggregation trunks. This limits the number of physically partitioned



.


configurations possible that support Layer-2 Fault Tolerance usingLink Aggregation.

— All ESM ports configured as members of a Layer-2 trunk must havethe same VLAN configuration. In addition:

– All trunk member ports must be assigned to the same VLANconfiguration before the trunk can be enabled.

– Changes to the VLAN settings of any trunk member cannot beapplied until the VLAN settings of all trunk members are similarlychanged.



.

51

Upgrading the Border Control Point7000 series


• "Maintenance updates" (page 52)

• "Upgrading to the BladeCenter-T" (page 68)

— "Firmware upgrades" (page 68)

– "Management Module firmware upgrade" (page 68)

– "Alteon ESM firmware upgrade" (page 70)

– "Blade Server firmware upgrade" (page 72)

— "BCP 7200 capacity upgrade" (page 73)

— "Configuration upgrades" (page 74)



.

52 Upgrading the Border Control Point 7000 series

Maintenance updates


• "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 descriptionThis chapter describes the upgrade tasks to be performed when updating amaintenance release.

Tools and utilitiesUpdates to the BCP 7200 are performed through the System ManagementConsole. For more information, see the System Management ConsoleUser Guide (NN42020-110).

Operations, administration, and managementThe Session Manager and Communication Server 2000 can try to contactthe BCP 7200 while the update is in progress, potentially generating errorlogs. To eliminate this potential and minimize impact to service, shut downthe BCP 7200 so that it does not accept new service requests. Whileshutting down, the BCP 7200 continues to process established mediasessions. These preexisting media sessions are cleared as the associatedcalls end. The BCP 7200 automatically transitions from the active into theinactive state when active media sessions are not present.

When this state transition occurs, it is safe to proceed with the updatewithout affecting service.

CAUTIONIt is possible to update and reboot one BCP 7200 in a chassis,while the BCP 7200 in the other half of the chassis continues torun the previous software. After one BCP 7200 is updated, theother BCP 7200 in the chassis can be shut down, updated, andrebooted. This rolling update only impacts available capacity anddoes 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 theprevious load is performed. A notification of the failure appears within theSystem Management Console.

If a component update fails after the initial stages of the update, it does notrollback automatically. A dialog box appears in the System ManagementConsole stating that the update failed and prompts the administrator todetermine whether a rollback must be performed. When the update passes,the BCP 7200 can be started again by the administrator.

Maintenance update tasksUpdate operations are issued to the BCP 7200 from the SystemManagement Console. The final stage of update causes a reboot of allmedia blades. When the update operation is complete on the BCP 7200,it can be brought back into service (active) with the updated software bythe administrator.

To avoid any conflicts with service requests from the Session Manager orCommunication Server 2000, the following procedure describes the stepsthat must be followed when updating a software load for the BCP 7200component.

Procedure 5Updating a software load for the BCP 7200 component

Step Action

1 From the System Management Console, shut down the BCP 7200component.

For more information, see "Shutting down the BCP 7200 component"(page 54).

2 Update the software load for the BCP 7200 component.

For more information, see "Deploying the BCP 7200 component"(page 55).

3 Start the load.

For more information, see "Starting the BCP 7200" (page 56).

4 This procedure is complete. If applicable, return to the higher leveltask flow or procedure that directed you to this procedure.

—End—



.


Shutting down the BCP 7200 componentThe following procedure describes how to shut down the BCP 7200component. To perform this procedure, the administrator must log on to theSystem Management Console. For detailed procedures on logging on tothe System Management Console, see the System Management ConsoleUser Guide (NN42020-110).

Procedure 6Shutting down the BCP 7200 component

Step Action

From the System Management Console

1 From the System tree, Click the plus sign (+) next to NetworkElements to expand the view of the folder.

2 Next, click the plus sign next to RTP Portals to expand the view ofthe folder.

The contents of this folder lists all BCP 7200s configured for the site.

3 Continue to expand the view of folders until the target BCP 7200is selected.

4 Click the NE Maintenance option.

A window appears.

5 Select the load to update, and click the Stop button to initiate shutdown.

Figure 12BCP 7200 shutdown

The Stop button shuts down the system. The Kill button locks theBCP 7200, and the Restart button stops and starts the system.

A confirmation window appears.

6 Click Yes to continue.



.


7 The BCP 7200 component shuts down gracefully and eventuallygoes into an inactive state when the last active media session ends(as in the General Information Area of the System ManagementConsole).


—End—

Deploying the BCP 7200 componentThe following procedure describes how to update a load for the BCP 7200component.

Updates to network components must be performed in a specific order. Formore information, see MCS 5100 Overview (NN42020-143).

Procedure 7Deploying the BCP 7200 component

Step Action


1 From the System tree, Click the Instance option. A window appears.

2 Select the Server and click the Edit button. You can update the ID,server, load, and engineering fields.

Figure 13Edit Instance variables

3 Click the NE Maintenance option.

4 Highlight the RTP1 server and click the Deploy button.

A window showing the progress of the update appears.



.


Figure 14Deploying the BCP 7200


—End—

Starting the BCP 7200The following procedure lists the steps necessary to start the BCP 7200.

Procedure 8Starting the BCP 7200

Step Action


1 After the update has completed, the state changes to active.

2 Click the Start button to cause the BCP 7200 to run the load.

Figure 15Start the BCP 7200


—End—



.


Service upgradesBladeCenter T BCPs do not require an upgrade.

Maintenance release upgradesFixes to issues reported in the BladeCenter T BCP are delivered throughthe existing or established MCS Maintenance Release (MR) procedure.

Whenever a Maintenance Release contains fixes to BladeCenter T BCPissues, the Release Notes will provide step-by-step instructions to guide theproper application of the Maintenance Release.

In most cases, the BCP MR upgrade process involves shutting down theBCP (no service interruption for sites engineered with redundancy, justreduced capacity) so that the service software can be deployed, and thenreturning the BCP to service.

The upgrade process is a straightforward procedure for standalonedeployments, because there is a one-to-one mapping of service nodeto service instance. Managing the service node is directly analogous tomanaging the service. However, the MR upgrade process is more complexwhen applied to fault-tolerant BCP Service Clusters, since multiple ServiceInstances execute a common service context over a set of associatedservice nodes.

Procedure 9Performing an MR upgrade on an In-Service Stand-Alone BladeCenter T BCPservice instance

Step Action

At the System Management Console,

1 Navigate to the RTP Portals Network Element representing theBladeServer participating in the 1+0 Service Cluster targeted for theMR Upgrade.

2 Open the NE Maintenance window.

3 Click Stop to shut down the BCP service instance on thisBladeServer.



.


Figure 16Stopping the NE Maintenance

The BCP service instance on the target BladeServer advertisesthat it is no longer available to process sessions (MPCP RSIPmessage to each associated Call Server) and continues to processits preexisting sessions.

After the last preexisting media session is released, the BCPbecomes Inactive.

4 Navigate to the RTP Portals folder in the config tree.


6 Click Undeploy to remove the previous version of the servicesoftware from the BladeServer.

Figure 17Undeploying the NE Maintenance

7 Navigate to the RTP Portals folder in the config tree.

8 Find the RTP Portal NE for the target BladeServer.

9 Open the NE Instance window.

10 Highlight the RTP Portal NE Instance.

11 Click the -/+ (edit) button to access the NE Instance configurables.



.


Figure 18Editing the NE Instance

12 In the Edit NE Instance window, select the load from the drop-downmenu.

13 Click Apply to commit the change.

14 Open the NE Maintenance window for this BladeServer.

15 Click Deploy to dispatch the service software to the BladeServer.

Figure 19Deploying NE Maintenance

16 After the Service Instance is successfully deployed, it must bestarted so that instantiation of the run-time structures occurs andthe service can be offered.

Navigate to the RTP Portals Network Element representing theBladeServer participating in this 1+0 Service Cluster.


18 Click Start to start up a BCP service instance on this BladeServer.



.


Figure 20Starting NE Maintenance

As the BCP service instance on the target BladeServer beginsto come into service, it retrieves its configuration data from theMCS 5100 Database Manager server. The BCP service instancedetermines that it is configured to participate in a Cluster, and thenlocates the specific Cluster configuration (Media Portal Cluster data).Instantiation of the service proceeds using the Media Portal ClusterData to configure the BCP Service in run-time.

Some of the first processes started by the BCP service instanceare those that support the N+1 fault-tolerant framework. In otherwords, they allocate the configured multicast address and port,start the reliable messaging framework to open the intraclustercommunications channel. As the N+1 fault-tolerant frameworkprocesses come up, they establish the Cluster in run-time. Sincethis is the first BCP service instance in the Cluster, it is determinedto be an active instance; in fact, since this is configured as a 1+0Stand-Alone this is the only instance of the service.

After the BCP service instance is configured as active, it issuesMPCP RSIP messages to all of its configured Call Controllers (theSession Managers and the Gateway Controllers as configured in theMedia Portal Cluster Data) to advertise its ability to provide service.After this point the BCP service instance can be called upon toservice calls.

—End—

BCP Service Cluster MR upgradeThe following activities are performed in the course of applying aMaintenance Release upgrade to a BCP Service Cluster.



.


Procedure 10Upgrading the BCP Service Cluster

Step Action


1 Remove the active BCP service instances from service as follows foreach BladeServer hosting an active Service Instance.

Figure 21BladeCenter T BCP Service Cluster MR Upgrade (1 of 4)

2 Shut down the BladeServer hosting the active BCP Instance usingthe following steps.

Navigate to the RTP Portals Network Element representing theBladeServer that is hosting the active BCP service instance for theService Cluster targeted for the MR upgrade.


4 Click Stop to shut down the active BCP service instance on thisBladeServer.



.


Figure 22Stopping NE Maintenance

The BCP service instance on the target BladeServer advertisesthat it is no longer available to process new sessions (MPCP RSIPmessage to each associated Call Server), and continues to processits preexisting sessions.

The standby BCP service instance remains in service and ready totake over in the event that the active Service Instance encountersa failure condition.

5 After the last preexisting media session is released, the target BCPbecomes Inactive. For larger-sized Service Clusters, repeat thisshutdown procedure for each BladeServer associated with an activeBCP service instance prior to taking the standby Service Instanceout of service.

6 Remove the Standby BCP from service. Shut down the standbyBCP service instance using the following steps.

Navigate to the RTP Portals Network Element representing theBladeServer that is hosting the active BCP service instance for theService Cluster targeted for the MR upgrade.



.


Figure 23BladeCenter T BCP Service Cluster MR Upgrade (2 of 4)


8 Click Stop to shut down the active BCP service instance on thisBladeServer.

The standby BCP service instance becomes Inactive.

9 Undeploy the Service Software from the hosting BladeServers usingthe following steps.



.


Figure 24BladeCenter T BCP Service Cluster Deploy (3 of 4)

Navigate to the RTP Portals folder in the config tree.

Figure 25Navigating to the RTP Portals folder


11 Click Undeploy to remove the previous version of the servicesoftware from the BladeServer.

12 Similarly, repeat this procedure for each BladeServer associatedwith this Service Cluster.

13 Deploy the service software to all BladeServers associated with thisService Cluster using the following steps.



.


14 Navigate to the RTP Portals folder in the config tree and find theRTP Portal NE for the target BladeServer

15 Open the NE Instance window, highlight the RTP Portal NEInstance, and click the -/+ (edit) button to access the NE Instanceconfigurables.

Figure 26Editing the Instance

16 In the Edit NE Instance window, select the Load from the drop-downmenu and click Apply to commit the change.

17 Open the NE Maintenance window for this BladeServer.

18 Click Deploy to dispatch the service software to the BladeServer.

Figure 27Deploying

19 Repeat this process to deploy service software to every BladeServerassociated with this Service Cluster.

20 After the Service Cluster is successfully deployed, it is broughtinto service (transitively) as each of the associated BladeServersis started. In this way the member Service Instances are startedindividually 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 softwareis deployed to the BladeServers participating in the Cluster. Thisprocess is repeated for each of the RTP Portal NEs representinga member of the Cluster.

Navigate to the RTP Portals Network Element representing aBladeServer participating in this 1+0 Service Cluster.

Figure 28BladeCenter T BCP Service Cluster Deploy (4 of 4)


22 Click Start to start up a BCP service instance on this BladeServer.Issuing the Start command to the RTP Portal NE representing theother RTP Portal NE associated with this 1+0 Fault-Tolerant ServiceCluster occurs in a similar fashion.

As the BCP service instance on the target BladeServer begins tocome into service, it retrieves its configuration data from the MCS5100 Database Manager. The BCP service instance determinesthat it is configured to participate in a Cluster, and then locates thespecific Media Portal Cluster data. Instantiation proceeds using theMedia Portal Cluster data to configure the service.

The other BCP service instance starts up in a similar fashion.

Some of the first processes started by the BCP service instanceare those that support the N+1 Fault-Tolerant Framework (forexample, they allocate the configured multicast address and portand start the reliable messaging framework to open the intracluster



.


communications channel). Since this is the first BCP serviceinstance in the 1+0 Cluster, it is determined by the N+1 Fault-TolerantFramework to be an active instance.

As the second BCP Instance starts up and joins the Cluster, the N+1Fault-Tolerant Framework determines that, since this is configuredas a 1+0 Cluster, this instance must be the Standby. This secondBCP Instance operates in Standby mode, checkpointing all servicedata from the active Service Instance and monitoring its status andwaiting for the opportunity to assume activity in the event that theactive Service Instance encounters a fault.

When a BCP service instance is configured as active, it issuesMPCP RSIP messages to all of its configured Call Controllers(Session Managers and Gateway Controllers as configured in theMedia Portal Cluster data) to advertise its ability to provide service.After this point, the Cluster has come into service and the activeBCP service instance is called upon to service calls. In the courseof processing service requests, all active BCP service instancescommunicate inside the Cluster to checkpoint service data to theStandby Service Instance and convey status so that the Clusterremains synchronized and able to survive the failure of one of itsmembers.


—End—



.


Upgrading to the BladeCenter T

The introduction of the BladeCenter T BCP brings with it a number ofupgrade considerations that span from the underlying platform (for example,BladeCenter T chassis subcomponents: Management Module firmware,Nortel Application Switch firmware, BladeServer firmware, as well as theintroduction of additional hardware to support growth in demand for theservice) to the BCP service (in other words, service-level software releaseupgrades, maintenance release upgrades, configuration upgrades). Theseareas are described in more detail in the following sections.

ATTENTIONFor a redundant System Manager only, following the upgrade of the BCP, returnto the System Manager upgrade procedure at the step "Deploying and startingthe Network Elements."

Firmware upgradesThis section describes how to upgrade various firmware.

IBM Management Module firmware upgradeThis procedure must be executed only if the Management Module firmwareis determined to be out of compliance with the approved firmware list.Firmware must be current as of the time the system leaves the configurationfacility. Subsequent firmware updates are provided through normal supportchannels when deemed necessary.

Procedure 11Upgrading the Management Module firmware

Step Action

At the Management Module web interface,

1 Log on to the Management Module web interface.



.

Upgrading to the BladeCenter T 69

Figure 29Logging on to the Management Module

2 From the MM Control menu, Click Firmware Update.

3 Click Browse to locate the firmware file to be used for the upgrade.

4 Click the desired .PKT file and select Open. The file (including thefull path) must appear in the box beside the Browse button.

Five packet files can be updated: CNETBRUS.PKT,CNETMNUS.PKT, CNETRGUS.PKT, REMOTEKM.PKT, andDUALPS2.PKT.

5 Click Update to begin the update process.

A progress indicator is displayed as the file is transferred totemporary storage on the Management Module. Remain on thispage until the transfer is complete, at which point a confirmationpage will appear.

6 Verify that the file type shown on the Confirm Firmware Updatepage is what you intended to update. If not, click Cancel.

7 Click Continue to complete the update process.

A progress indicator is displayed as the firmware update progresses.Remain on this page until the update process is complete, at whichpoint a status page will appear to indicate whether the updateis successful. Additional instructions will appear on this page ifnecessary.

8 Repeat the preceding steps for each packet to be updated.

9 Restart the Management Module. This will not affect the BladeServerpower status.



.


From the MM Control menu, click Restart MM.

10 Click Restart.

11 Click OK to confirm that you want to restart the management module.The management module will restart. The current connection tothe management module is lost. You will need to reconnect to themanagement module web interface using the configured IP addressfor the external interface, if changed.

—End—

Nortel Application Switch firmware upgradeThis procedure must be executed only if the Nortel Application Switchfirmware is determined to be out of compliance with the approved firmwareversion. Firmware must be current as of the time the system leaves theconfiguration facility. Subsequent firmware updates are provided throughnormal support channels when deemed necessary.

The Nortel Application Switch uses two firmware images: an OS image anda Boot image. Firmware is transported to the Nortel Application Switchusing FTP/TFTP from a remote FTP/TFTP server that is reachable throughthe external ports on the Management Module.

To update the firmware for the Nortel Application Switch, from the commandline, use the following procedures. The following steps reflect the use of aTFTP server. A FTP server can also be used.

Procedure 12Accessing the Nortel Application Switch

Step Action

At the web browser,

1 Using Web-based access as an example, the following procedurecan be followed to log on to the Nortel Application Switch as anadministrator and so to access operational, administrative, andmaintenance functions:

Access the Nortel Application Switch (for example, by using its IPAddress) through a Web-browser on the Managed Network. Priorto permitting access, the Nortel Application Switch will prompt for aUser Name and Password to authenticate the access request.

The User ID and Password fields are case-sensitive. To maintainsystem security, change the password after you log on for the firsttime.



.


2 After the user is authenticated, the Nortel Application Switch permitsaccess and displays the main administrative web-page from whichall administrative functions can be run.

—End—

Procedure 13Upgrading the Nortel Application Switch firmware

Step Action

1 Download the Nortel Application Switch software package (zip file)to the machine where the TFTP server resides.

2 Extract the Boot and OS image files into a directory. Enable theserver and configure its default directory to the one where the imagefiles reside.

3 Download the Nortel Application Switch software package (zip file)to the machine where the TFTP server resides (step 1).

4 Access the Nortel Application Switch command line.

5 Navigate from the main menu to the System -> Config/ImageControl level.

6 The Nortel Application Switch provides storage for two OS imagesand one Boot image.

Load the OS image into one of the image banks.

7 Reset the switch.

8 Load the Boot image.

9 Reset the switch.

When you reset the switch, it boots using the selected image (1 or2). Ensure that you are booting from the upgraded image (see theNext Boot Image Selection field).

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 byloading the upgrade into the other image bank and resetting theswitch using the new image. (Use the /boot/image command toselect the preferred image.)

11 Answer Y to the confirmation question and then wait for the upgradeto complete successfully.

12 Enter:

/boot/reset

You must reset the switch to activate the new image. Resettingthe switch logs you out of the CLI, so steps 4 and 5 need to beexecuted again before proceeding to the next step. A switch resetis completed in approximately 60 seconds.

13 Upgrade the boot image by entering:

/boot/gtimg boot TADDR 1.0.1.6_Boot.img

14 Answer Y to the confirmation question and then wait for the upgradeto complete successfully.

15 Enter:

/boot/reset

For more information, see the Nortel Layer2/3 GbE Switch Modulefor IBM e-server BladeCenter T Installation Guide.

—End—

BladeServer firmware upgradeThis procedure must be executed only if the BladeServer firmware isdetermined to be out of compliance with the approved firmware version.Firmware must be current as of the time the system leaves the configurationfacility. Subsequent firmware updates are provided through normal supportchannels when deemed necessary.

Procedure 14Upgrading the BladeServer firmware

Step Action

At the Management Module’s web interface,

1 Log on to the Management Module web interface.

2 From the Blade Tasks menu, click Firmware Update.



.


Figure 30Firmware update

3 From the Upgrade Blade Firmware screen, select the targetBladeServer from the target drop-down menu.

4 In the Firmware file field, click Browse.

5 From the resulting File Upload dialog box, select the firmware file tobe used for the upgrade, and then click Open.

6 Click Update.

For further details, see the IBM BladeCenter Management ModuleUser’s Guide.

—End—

BCP 7200 capacity upgradeAs the demand for service grows, it is possible to grow the installed base ofBCPs through the introduction of a BladeCenter T chassis or the additionof BladeServers into an existing BladeCenter T chassis (to supply servicenodes on which new BCP service instances can run).

The addition of hardware (chassis or BladeServers in existing chassis) iseasily accomplished using the appropriate installation and commissioningprocedure to properly position the hardware to host the Service Instances.

For cases where capacity is expanded by adding BladeServers to anexisting chassis, the BladeServers can be inserted and fully installed andcommissioned without impact to the Service Instances running on the otherBladeServers in the chassis. However, actually establishing an activelyrunning BCP service instance on the BladeServer requires associatedconfiguration datafill (specifically, Service Instances in the Media PortalCluster data structure, and RTP Portal NEs in the RTP Portals entity).



.


The simplest way to increase capacity, without impacting service, is throughthe introduction of BCP Service Clusters (either 1+0 standalone or N+1Fault-Tolerant) on hardware, as this entails the straightforward addition ofunit-capacity into the system without having to coordinate with the existinginstalled base.

Expanding the capacity of existing N+1 Fault-Tolerant Clusters is morecomplex. This complexity stems from the need to update the configurationfor an in-service topology (in other words, changes to the Media PortalCluster entity for an operational Service Cluster) and to coordinate thedelivery of this Service Cluster configuration to service nodes associatedwith the Service Cluster.

Since the BCP does not support LiveUpdate (the ability to consumeconfiguration data changes on the fly) it is necessary to cycle the whole BCPService Cluster out of service and back into service to pick up configurationchanges. Unfortunately, while the BCP is out of service, the service capacityof the system is temporarily reduced.

Configuration upgradesThe BladeCenter T BCP variant does not support the ability to consumeconfiguration data changes on-the-fly (LiveUpdate). As a consequence, itis necessary to cycle the whole BCP out of service and back into serviceto pick up configuration changes. Unfortunately, while the BCP is out ofservice, the service capacity of the system is temporarily reduced.

With respect to configuration upgrades for the 1+0 standalone BladeCenterT BCP Service Cluster, the single RTP MediaPortal NE is shut down (Stopcommand) and quickly restarted (Start command) so that the configurationdata is picked up. This procedure is similar to that used to apply MRUpgrades to the standalone BCP except that there is no need to Undeployand Deploy the service software.

Configuration changes to existing N+1 Fault-Tolerant Clusters are morecomplex because the entire Service Cluster must be cycled out of serviceand back into service so that there is run-time synchronization of theconfiguration data and so that all Service Instances run with the sameservice context. The extent of the impact of the temporary decrease incapacity accompanying this action can be large (as is the case for a 7+1fault-tolerant BCP Service Cluster). The actual procedure used to applyconfiguration changes to a BCP Service Cluster is similar to that used toapply MR Upgrades to a BCP Service Cluster except that there is no needto Undeploy or "Deploy" the service software.



.

75

Fault management


• "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 managementThe system handles network fault management through the reporting ofalarms and logs to the Fault Performance Manager. You can view BCP 7200alarms and logs from the System Management Console. For further detailsrelated to alarms, see the Alarm and Log Reference (NN42020-703).

Fault toleranceThe BCP 7200 provides base capabilities that significantly improve theperformance and reliability of the system if a fault occurs. These capabilitiesinclude:

• Dynamic Pool Registration provides a basic mechanism that ensuresresource availability and utilization in the event of loss of communicationswith a call server.

Dynamic Pool Registration provides this mechanism through generationof periodic registration messages (over the control channel) to each ofthe call servers configured for the BCP 7200. This function works intandem with call server redundancy to ensure that BCP 7200 resourcescontinue if a call server fails.

The BCP 7200 is configured to advertise its availability with the standbycall server. This configuration enables the standby server to immediatelybegin using the BCP 7200 for session requests whenever a failurecondition occurs on the active call server.



.

76 Fault management

• Idle Session Detection enables the BCP 7200 to detect and recovermedia resources associated with idle media sessions. This basiccapability enables the system to recover resources as well as maintaincapacity and performance.

• Media Survivability enables the BCP 7200 to permit media sessionsto survive (through to session completion) in the absence of controlsignaling from the call server. This capability enables the system topermit media sessions to continue through to completion in the wakeof loss of communications with the call server.

• Host IP Failover provides redundant (active/standby) networkconnectivity for the BCP 7200 host card so that if a network issueaffects one of the connections, the other connection assumes activity.This functionality enables the BCP 7200 to maintain control and OAMconnectivity if a network fails.

• Shared Resource enables the distribution of BCP 7200 resourcesthrough association with multiple call servers. The strategy of distributingmedia sessions over multiple BCP 7200s strengthens the network abilityto continue processing sessions if a condition fails. Failures result indiminished capacity, but not necessarily a service outage, since manyother BCP 7200s remain available for the call server to use.

• Host CPU Recovery provides for media stream survival through a hostCPU failure and subsequent recovery. After host CPU failure, mediastreams on subtending media blades continue to flow undisturbed.During the subsequent host CPU recovery process, communications arereestablished with the media blades, and available capacity informationis retrieved from each of the media blades. After the BCP 7200 resumesservice, it offers the remaining available capacity on the media bladesfor processing sessions.

Fault management proceduresThis section describes how to obtain alarm information and clear alarms.

Alarm surveillanceThe following procedure lists steps to obtain information regarding alarms.

Procedure 15Obtaining alarm information

Step Action


1 On the Alarm Bar, right-click and select Logical View.

A window appears.



.

Network fault management 77

2 Open the RTP Portal folder by clicking on the plus sign. Highlightthe target.

3 At the bottom of the Logical ViewsLogical Views screen, click theAlarm Browser button.

Figure 31Alarm Browser

4 Select an alarm to view alarm details. For alarm severityclassification, see the Alarm and Log Reference (NN42020-703).

—End—

Clearing an alarmThe following procedure lists steps to clear an alarm.

Procedure 16Clearing an alarm

Step Action


1 From the Alarm Browserwindow, click the alarm row.

Information regarding the alarm appears in the information screen atthe bottom of the window.

2 Click the Clear button.



.

78 Fault management

—End—

BCP 7200 alarmsThis section describes how to clear certain alarms that affect the BCP7200. For more information about BCP 7200 alarms, see Alarm and LogReference (NN42020-703).

Procedure 17Clearing the RTP101 Alarm (Blade out of service on initialization)

Step Action

1 Ensure network connectivity between the host and blade, or networkconnectivity on its other interfaces (link LED is lit on the blade card).Verify that the media blade is running (Telnet to the suspect mediablade).

2 Contact your next level of support with the results of these tests.

—End—

Procedure 18Clearing the RTP102 Alarm (BCP 7200 Out of Service)

Step Action

1 Ensure network connectivity between the host and blade, or networkconnectivity on its other interfaces (link LED is lit on the blade card).

2 Contact your next level of support.

—End—

Procedure 19Clearing the RTP103 Alarm (Portal Port Usage)

Step Action

1 Ensure the configured capacity limits (the ports configurationparameter) provide adequate capacity to handle session load. Thisalarm is cleared after occupancy falls following the configured onsetthreshold.

2 Contact your next level of support.



.


—End—

Procedure 20Clearing the RTP104 Alarm (Host Interface Failure)

Step Action

1 Ensure network connectivity. Verify that interfaces have a goodconnection to the network (link LED is lit on the host card).

2 Ensure that IP failover functionality is enabled on the BCP 7200.Verify that the host IP failover settings are properly configured duringinstallation and commissioning. Verification and configuration ofsettings is performed using the PortalConf.pl script on the Host.This alarm is cleared after both host Network Interfaces do notexhibit any communications problems.

3 If the alarm persists, contact your next level of support.

—End—

Additionally, alarms are generated whenever the Session Manager does notreceive responses to requests to the BCP 7200. RTP108 and RTP 109 aregenerated by the Session Manager to indicate that the connection with theBCP 7200 is lost. For information regarding these alarms, see the Alarmand Log Reference (NN42020-703).

Informational and communication logsLogs assist with the maintenance and operation of the BCP 7200.Information logs begin with the number 9 (RTP906), where communicationlogs begin with 1 (RTP108). Administrative logs begin with the number8 (RTP801).

• Host Recovery-Mode Initiated, RTP906. Produced upon recovery ofthe BCP 7200 Host application upon discovery of preexisting mediasessions. No action is required.

• Host Recovery- Mode Completed, RTP907. Produced during the HostCPU recovery process to report the number of connections recoveredon a media blade. No action is required.

• Lost connection with BCP 7200, RTP108. Ensure the referencedBCP 7200 is accessible over the network, and functional. If it is notfunctional, restart the BCP 7200.



.

80 Fault management

• Blade Recovery-Mode Initiated, RTP909. Indicates that the HostCPU was able to reestablish communication with a subtending mediablade and that the media blade is supporting connections. No actionis required.

• Blade Recovery-Mode Completed, RTP910. Indicates the Host CPUwas able to reestablish communication with a subtending media bladeand reports the number of connections over which the Host CPU is ableto restore control. No action is required.

• Connection Map Increase Capacity, RTP911. Generated whenever itis necessary for an increase in the size of the Hash Map used to storeconnection information. This can indicate a need for additional BCP7200 resources.

• Connection Map Increase Capacity Denied, RTP912. Generatedwhenever a request for an increase in the size of the Hash Map isdenied. This indicates the Hash Map is already double in size, andprevents unbounded increases in the size of the Connection Map.Report this log to your next level of support.

• Connection Map Increase Capacity Failed, RTP913. Generatedwhenever a request for an increase in the size of the Hash Map fails dueto some unforeseen software issue. Report this log to your next levelof support.

• Connection Not Found, RTP914. Generated whenever an audit isperformed over the Connection Map, and a particular connection isnot found on the corresponding media blade to match the entry in theConnection Map. No action is required.

• Connection Idle, RTP915. Generated whenever an audit is performedover the Connection Map, and a particular connection is found idle onthe corresponding media blade. No action is required.

• Connection Exceeds Long Idle Duration, RTP916. Generatedwhenever an audit is performed over the Connection Map, and aparticular connection is found on the corresponding media blade thatexceeds the Long Idle Duration threshold. No action is required.

• Connection Exceeds Long Call Duration, RTP917. Generatedwhenever an audit is performed over the Connection Map, and aparticular connection is found on the corresponding media blade thatexceeds the Long Call Duration threshold. No action is required.

• Failed to Send Signal, RTP118. Generated whenever an attempt todispatch an outgoing signal fails. No action is required.

• Failed to Reboot IO Exception, RTP919. Generated whenever arequest for reboot of the system fails due to a software request for thisreboot. Report this log to your next level of support.



.


• No Blades Configured, RTP920. Generated whenever the BCP 7200initiates in a state in which no media blade information is configuredfrom the System Management Console. Install the media blade toactivate the BCP 7200.

• Unknown Proxy, RTP921. Generated whenever a request for service ismade from an unknown proxy, one which is not datafilled for this BCP7200. Investigate the source proxy to ensure that it is a valid networknode, and if it must be part of the BCP 7200 datafill.

• Unable to Register with Proxy, RTP922. Generated whenever anattempt to send a registration message to a proxy fails.

• Host Interface Status File Problem, RTP923. Generated during afailed attempt to establish a file handle for the interface status file, readfrom the file handle, or the handle does not exist. Verify that the hostIP failover setting is properly configured from the System ManagementConsole. Report this log to your next level of support.

• Lost connection with Last BCP 7200, RTP105. Ensure the referencedBCP 7200 is functional. If not, the user is required to restart the BCP7200.

• Blade out of Service for Network Difficulty, RTP106. Ensure networkconnectivity between the host and blade, or network connectivity on itsother interfaces (link LED is lit on the blade card).

• Blade out of Service for Public Network Difficulty, RTP107.Ensure network connectivity between the host and blade, or networkconnectivity on its other interfaces (link LED is lit on media blade, pingthe media blade).

• Lost connection with BCP 7200, RTP109. Ensure the referenced BCP7200 is accessible over the network and functional. If it is not functional,restart the BCP 7200.

• BCP 7200 does not support live configuration update, RTP801.Configuration data change does not take effect until the BCP 7200 isreinitialized using the Stop/Start, Restart, or Kill/Start maintenancecommands. Stop and then start the Portal so that it picks up theconfiguration change.

• System Property Portal.Config.BRHOME is not defined, RTP802.The Portal.Config.BRHOME is not defined. Contact your next level ofsupport.

• Portal Out of Service because invalid number of Call ServersDatafilled, RTP803. Portal Out of Service because invalid number ofCall Servers are datafilled for a BCP 7200. Three Call Servers aredatafilled against an RTP instance that supports a maximum of two.Ensure a valid number of Call Servers are datafilled for a BCP 7200.



.

82 Fault management

• Host Recovery-Mode Initiated, RTP110. Produced during recoveryof the BCP 7200 Host application after discovery of preexisting mediasessions on a media blade. No action is required.

• Blade Recovery-Mode Completed, RTP111. Indicates that the hostcan establish communication with a subtending media blade. This logalso reports the number of connections over which the Host was able torestore control. No action is required.

• Host Recovery-Mode Initiated, RTP112. Produced at the start of theBCP 7200 host application recovery process. This process attemptsto reconstitute control over all preexisting media sessions. No actionis required.

• Host Recovery - Mode Completed, RTP113. Produced during the hostrecovery process to report the number of connections recovered on aspecific media blade. No action is required.

• Host Recovery - Mode Blade Communication Failure, RTP114.Produced during the host recovery process to report the number ofmedia blades with which the Host failed to establish communications.No action is required.

• No Blades Configured, FTP200. Generated whenever the BCP 7200initializes in a state in which media blade information is not configured.The BCP 7200 requires at least one media blade to provide service.Install a media blade and configure it from the System ManagementConsole to successfully activate the BCP 7200.

• Failed to Reboot IO Exception, RTP201. Generated whenever arequest 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 ismade from an unknown proxy, one which is not configured for the BCP7200. Investigate the source proxy to ensure that it is a valid networknode. Either update the configuration to include the node or securethe control plane.

• Unable to Register, RTP203. Generated whenever an attempt to senda registration message to one of the configured proxies fails. Verifythat the configuration data represents an existing proxy. Verify that theaffected proxy exists and is reachable in the network.

• Connection Not Found, RTP204. Generated whenever an audit isperformed over the Connection Map, and a particular connection is notfound on the corresponding media blade. Report this log to your nextlevel of support.

• Connection Idle, RTP205. Generated whenever an audit is performedover the Connection Map, and a particular connection is unexpectedly



.


found idle on the corresponding media blade. The invalid idle connectionis identified in this log. No action is required.

• Connection Exceeds Long Idle Duration, RTP206. Generatedwhenever an audit is performed over the Connection Map, and aparticular connection is found on the corresponding media blade whichexceeds the Long Idle Duration threshold. No action is required, unlessthis log is generated excessively, in which case, the Long Idle Durationperiod can be configured for a longer interval.

• Connection Exceeds Long Call Duration, RTP207. Generatedwhenever an audit is performed over the Connection Map, and aparticular connection is found on the corresponding media blade whichexceeds the Long Call Duration threshold. No action is required.

• Host Interface Status File Problem, RTP208. Generated during afailed attempt to access the interface status file. Verify the host IPfailover settings are properly configured using the PortalConfig.pl scripton the Host. Report this log to your next level of support.

• Connection Map Increase Capacity, RTP300. Generated whenever itis necessary for the BCP 7200 to autonomously increase in the size ofthe Hash Map used to store connection information. This can indicate aneed for additional BCP 7200 resources. Report this log to your nextlevel of support.

• Connection Map Increase Capacity Denied, RTP301. Generatedwhenever a request for an increase in the size of the Hash Map isdenied. This log indicates that the Hash Map is already increased insize and prevents unbounded increases in the size of the ConnectionMap. Report this log to your next level of support.

• Connection May Increase Capacity Failed, RTP302. Generatedwhenever a request for an increase in the size of the Hash Map fails dueto some unforeseen software issue. Report this log to your next levelof support.

System logsSystem logs are discussed in detail in the Alarm and Log Reference(NN42020-703).



.

84 Fault management



.

85

Configuration management

How this chapter is organizedThis chapter includes information regarding the reconfiguration andmaintenance of the BCP 7200. It assumes that the BCP 7200 is installedand properly deployed. For more information about installation, see BorderControl Point commissioning procedures

The chapter is organized as follows:

• "Tools and utilities" (page 85)

• "Run-Time Service Configuration Parameter Mapping" (page 86)

• "Border Control Point 7200 configuration" (page 88)

— "Configuring the BladeCenter-T service node" (page 88)

— "Configuring the BladeCenter-T service data" (page 88)

— "Configuring the BladeCenter-T" (page 98)

— "Stand-alone instantiation" (page 111)

— "Service Cluster Instantiation" (page 115)

— "Run-Time Service Configuration Parameter Mapping" (page 86)

Tools and utilitiesYou deploy and configure the BCP at the System Management Console andthe Provisioning Client. For more information, see System ManagementConsole User Guide (NN42020-110), and the Provisioning Client UserGuide (NN42020-105).

Administrators can initially deploy and configure the BCP componentusing the Add operation on the System Management Console. The queryoperation is used for viewing configuration property values. The modifyoperation is used for changing the values of configuration properties anytimeafter initial deployment.



.

86 Configuration management

Configuration changes do not occur in real-time. Rather, they arepersistently stored in the Management Database Server until the BCP isrestarted.

Run-Time Service Configuration Parameter MappingTable 2 "Service configuration parameters for the BladeCenter T" (page 86)maps and compares the location of service configuration parameters forthe BladeCenter T service nodes.

Table 2Service configuration parameters for the BladeCenter T

BladeCenter T

Parameter Data Structure

Server(OAM-only IPaddr)

Network Elements-> Media Portals-> RTP Portals-> Instance

(RTP Portals Network Element)

Service ID

Control IPAddrSubnetMask

Net1 Media IPAddrSubnetMask


Control IPAddr

Net1 Media IPAddr

Net2 Media IPAddr

Network Elements-> Media Portals-> RTP Portals-> Service Instances

(BCP Service Cluster Data)

Number of Port

Min Port Value

Max Port Value

Network Elements-> Media Portals-> Media Portal Cluster->Configuration Parameters(BCP Service Cluster Data)



.

Run-Time Service Configuration Parameter Mapping 87

BladeCenter T


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

Network Elements-> Media Portals-> Media Portal Cluster->Fault Tolerance(RTP Portals Network Element)

Refers to-> Network Data and Mtc->Static Routes

-> Media Portal Cluster

->Static Routes(RTP Portals Network Element)

Session Manager Network Elements-> "Media Portals-> Media Portal Cluster->Session Managers (RTP Portals NetworkElement)

Discovery Probe Timer Period

Gateway Controller

Discovery Probe Timer Period

Network Elements->Media Portals->Media Portal Cluster->Gateway Controllers(RTP Portals Network Element)




.


Border Control Point 7200 configuration

How this chapter is organizedThe chapter is organized as follows:

• "Configuring the BladeCenter-T service node" (page 88)

• "Configuring the BladeCenter-T service data" (page 88)

• "Configuring the BladeCenter-T" (page 98)

• "Stand-alone instantiation" (page 111)

• Procedure 24 "Instantiating the service cluster" (page 117)

• "Run-Time Service Configuration Parameter Mapping" (page 86)

Configuring the BladeCenter T service nodeThe configuration of either variant of the BCP service node is built on theRTP Portal NE as represented in the RTP Portals data structure. ForBladeCenter T service nodes, the platform-level configuration parametersare harvested from the RTP Portal NE. All service-level configuration iscontained in the Media Portal Cluster data structure. See the Run-TimeService Configuration Parameter Mapping for detailed mapping of thelocation of service-level configuration parameters for each service nodevariant.

Configuring the BladeCenter T service dataThe Media Portal Cluster entity contains the common service dataconfiguration information and the BCP logical service instances (bothstandalone and clustered) that run on the BladeCenter T. The commonservice data is an abstraction specific to the BladeCenter T platform thatis used to define a common run-time service context that is common to allservice instances in a service cluster.

The information contained in the Media Portal Cluster data structureincludes:

• Service Instances (definition of each active BCP service instance inthe cluster).

• Configuration Parameters (the operational service configuration thatruns by each active instance).

• Fault-tolerance (the parameters that define the Peering-Plane used byBCP service instances for intracluster communications).

• Static Routes (an easier way to manage the configuration of staticroutes).



.

Border Control Point 7200 configuration 89

• Session Managers (data structure that enables specification of the MCPSIP Session Servers that are to receive service).

• Gateway Controllers (data structure that enables specification of the CS2000 Gateway Controllers that are to receive service). See the MediaPortal Cluster: Data Structures for a more comprehensive listing of theconfiguration parameters present in this data structure.

Table 3Media Portal Cluster: Data Structures

Data type Parameter name Parameter Parameter description

Service ID Type: IntegerRange: 0–6

The unique ServiceIdentifier associated withthis logical BCP serviceinstance.

Control IPAddrSubnetMask

The subnet mask thatdefines the scope of thenetwork to which the ControlIP address is associated.


The subnet mask thatdefines the scope of thenetwork to which the Net1IP address is associated.


Listing ofdatafilled SubnetMasks (in NetworkData folder)

The subnet mask thatdefines the scope of thenetwork to which the Net2IP address is associated.

Control IPAddr The IP address that is usedfor MPCP communicationsin the Control-Plane.

Net1 Media IPAddr The IP address that is usedto convey media to/fromNet1 (a logical interface) inthe Media-Plane.

Service InstanceData (Defines eachunique active ServiceInstance. This datacan recur up to seventimes.)

Net2 Media IPAddr

Listing of datafilled Addresses(in Network Datafolder)

The IP address that is usedto convey media to/fromNet2 (a logical interface) inthe Media-Plane.



.



Number of Port Type: IntegerRange:1–10 000

The number of media portsthat the active ServiceInstances in this ServiceCluster make available toprovide service. OverridesNumber of Port parameterpresent in the RTP PortalNE Blade Data.

Min Port Value Type: IntegerRange:1026–65 535

The lower bound on therange of media ports thatcan be allocated. OverridesMin Port Value parameterpresent in the RTP PortalNE Blade Data.

Max Port Value Type: IntegerRange:1026–65 535

The upper bound on therange of media ports thatcan be allocated. OverridesMax Port Value parameterpresent in the RTP PortalNE Blade Data.

Call Legs Type: IntegerRange:1026–65 535

***Do not change.*** Thisis an engineered valuerelated to the number ofsimultaneous sessions.

Critical PortUsageAlarm Level

Type: PercentRange: 0–100Default= 90

The threshold at which aCritical Alarm is raised toreport that the number ofmedia ports in use meetsor exceeds the percentageof the total available.Overrides the CriticalPortUsageAlarmLevel parameterpresent in the RTP PortalNE Config Parm GroupBladeRunner.

Major PortUsageAlarm Level


The threshold at which aMajor Alarm is raised toreport that the number ofmedia ports in use meets orexceeds the percentage ofthe total available.

Overrides theMajorPortUsageAlarmLevelparameter present in theRTP Portal NE Config ParmGroup BladeRunner.

Configurationparameters(constitutes theService Data thatdefines a servicerun-time environmentthat is common toall active ServiceInstances)



.



Minor PortUsageAlarm Level


The threshold at which aMinor Alarm is raised toreport that the number ofmedia ports in use meets orexceeds the percentage ofthe total available.

Overrides theMinorPortUsageAlarmLevelparameter present in theRTP Portal NE Config ParmGroup BladeRunner.

Long Call Duration Type: IntegerRange:1–65 535

The number of times theIdle Session Audit mustrun for an active sessionto be considered a LongCall. After classificationas a Long Call, thesession is either terminatedautonomously by the MediaPortal Service, or it isreported to the controllingCall Server.

Overrides theLongCallDurationparameter present inthe RTP Portal NE ConfigParm Group BladeRunner.

Long IdleDuration Type: IntegerRange:1–65 535

The number of times theIdle Session Audit must runfor a validly idle sessionto be considered a LongIdle. After classificationas a Long Idle, thesession is either terminatedautonomously by the MediaPortal Service, or it isreported to the controllingCall Server.

Overrides LongIdleDurationparameter present in theRTP Portal NE Config ParmGroup BladeRunner.

Idle Session AuditPeriod

Type:MillisecondsRange:

The period of the IdleSession Audit.



.



0–3 600 000 Overrides IdleSessionAuditPeriod parameter present inthe RTP Portal NE ConfigParm Group BladeRunner.

Poll Timer Delay Type:MillisecondsRange:

0–3 600 000

The interval during whichthe Poll Timer delaysstarting up after the servicefirst initializes.

Overrides PollTimerDelayparameter present in theRTP Portal NE Config ParmGroup "BladeRunner".

Poll Timer Interval Type:MillisecondsRange:

0–3 600 000

The period of the Pollmechanism.

Overrides PollTimerIntervalparameter present in theRTP Portal NE Config ParmGroup BladeRunner.

Static RTP Ports Type:CheckboxON|OFF

Controls the algorithm usedto allocate and managemedia ports.

If checked (ON), thiscauses the Number of Portparameter to be ignored andevery even-numbered portbetween the Min Port Valueand the Max Port Value isallocated to provide service.

If unchecked (OFF), portrandomization mechanismsare used to ensure thatthe pool of allocated mediaports is always rotated.

Overrides StaticRTPPortsparameter present inthe RTP Portal NEConfig Parameter GroupBladeRunner.



.



MultiCast IP Listing of datafilled Addresses(in Network Datafolder)

The IP address that isused in combinationwith the MultiCastPort as the basis forestablishing the intraclustercommunications channel inthe Peering-Plane.

MultiCast Port Type: IntegerRange:0–65 535

The UDP port that is usedin combination with theMultiCast IP as the basis forestablishing the intraclustercommunications channel inthe Peering-Plane.

HeartBeat Interval Type: Integer The period between theheartbeats used to maintainthe highly-available BCPService Cluster.

Fault-tolerance Data

(Defines aspectsof the fault-tolerantframework)

Stand Alone Type: CheckboxON|OFF

When checked, thisparameter designatesa non-redundant 1+0standalone configuration ofthe BladeCenter T BCP.

When unchecked, thisparameter designates aredundant N+1 BCP ServiceCluster configuration of theBladeCenter T BCP.

Static Routes

<Static Routesconfigured for thisService Cluster

MPCluster StaticRoutes

Listing ofdatafilled StaticRoutes (inNetwork Datafolder)

The Static Routes requiredto reach devices far off inthe network.

Session Manager Listing ofdatafilled SessionManagers (inNetwork Elementfolder)

Drop-down menu ofavailable SessionManagers.

Overrides the SessionManager Data specified inthe RTP Portal NE.

Session Managers

There can be up to20 total Call Servers(total of SessionManagers andGateway Controllersfor each ServiceCluster).

Discovery ProbeTimer Period

Type:MillisecondsRange:0–3 600 000

Field specifying thefrequency of the periodicMPCP RSIP to thecontrolling Call Servers.

The value entered into thisfield overrides the valuefor the Discovery Probe



.



timer field for each instanceof Session Manager Dataspecified in the RTP PortalNE.

Gateway Controller Listing of datafilled CS2K GatewayControllers(in NetworkElement/CallServer 2000Integration folder)

Drop-down menu ofavailable GWCs thatoverrides the SessionManager Data specified inthe RTP Portal NE.

Gateway Controllers

There can be up to20 total Call Servers(total of SessionManagers andGateway Controllersfor each ServiceCluster.) Discovery Probe

Timer PeriodType:MillisecondsRange:0–3 600 000

Field specifying thefrequency of the periodicMPCP RSIP to thecontrolling Call Servers.

The value entered in thisfield overrides the valuefor the Discovery Probetimer field for each instanceof Session Manager Dataspecified in the RTP PortalNE.

A sample of the System Management Console rendering of the MediaPortal Cluster data structure is shown in the System Management Console:Media Portal Cluster Data Structure.



.


Figure 32System Management Console: Media Portal Cluster Data Structure

Static Routes Data StructureThe Static Routes entity contains the static routes entries that are populatedon the BladeCenter T service nodes as they come into service.



.


Figure 33System Management Console: Static Routes Data Structure

The procedure for creating a static route and adding it to the BladeCenter TBCP is described in Creating a static route and adding it to the BCP 7200(also see System Management Console: Static Routes Data Structure).

Procedure 21Creating a static route and adding it to the BCP 7200

Step Action


1 Ensure that the IP addresses of interest are defined in the site usingthe following steps:

a. Open the Network Data and Mtc folder in the config tree.

b. Click the Addresses data structure to open the Addresseswindow.



.


c. Click the Add (+) button to open the Add Address window.

d. Enter a unique Logical Name and IP Address pair.

2 Repeat this process to add as many IP address entities as requiredinto the site.

3 Identify specific network nodes or network resources that areexternal to the site (those that require special routing considerations)by using the following steps:


b. Click the External Nodes data structure to open the ExternalNodes window.

c. Click the Add (+) button to open the Add External Node window.

d. In the Add External Node window, identify the IP addresses inthe site that require special route considerations by associatingthem with a unique external node name. Click Apply to committhis data.

e. Repeat this process for each remote network node or networkresource.

4 For these remote network nodes or network resources, identify theGateways that can route to them and the subnet masks that definetheir extent.

Identify Gateways in the site by using the following steps:


b. Click the Gateways data structure to open the Gateways window.

c. Click the Add (+) button to open the Add Media LAN Gatewaywindow.

d. In the Add Media LAN Gateway window, identify the IPaddresses in the site that represent remote network gateways byassociating them with a unique gateway name. Click Apply tocommit 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:


b. Click the Subnet Masks data structure to open the Subnet Maskswindow.

c. Click the Add (+) button to open the Add Subnet Mask window.



.


d. In the AddSubnet Mask window, specify the subnet mask thatdefines the extent of the remote network and associate it witha unique subnet Mask Name.

e. Click Apply to commit this data.

f. Repeat this process to define the extent of each remote network.

6 Colocate the data identifying the remote network nodes andresources, remote network extent, and remote gateways into a staticroute definition that specifies when and how to reach those remotenetwork nodes or resources. Perform the following steps:


b. Click the Static Routes data structure to open the Static Routeswindow.

c. Click the Add (+) button to open the Add Static Routes window.

d. In the Add Static Routes window, provide a Static Route Nameto uniquely identify this static route.

e. Identify the gateway that knows how to route to this remotenetwork by selecting it from the Gateway pick-list (a listing of allGateways defined in this site)

f. Identify the remote network node or resource by selecting it fromthe Destination Network (External Node) pick-list (a listing of allExternal Nodes defined in this site).

g. Identify the extent of the remote network by selecting it from theDestination Subnet Mask pick-list (a listing of all Subnet Masksdefined in this site).

h. Click Apply to commit this data.

—End—

Configuring the BladeCenter TYou configure the BladeCenter T BCP 7200 through the MCS SystemManagement Console and through a combination of traditional RTP Portalsdatafill (the RTP Portals Network Element used to describe the underlyingBladeCenter T service nodes and Media Portal Cluster datafill that definesthe logical service context.

You configure the BladeCenter T BCP with parameters that are consistentacross service nodes. However, the location from which these parametersare taken varies with the service node type.



.


For BladeCenter T service nodes, the configuration is partitioned intoseparate data structures that represent service-level parameters (theMedia Portal Cluster data structure) and platform-level parameters (theRTP Portal NE, as represented by the RTP Portals data structure). Mostof the parameters present in the Media Portal Cluster still have equivalentrepresentations existing in the RTP Portal NE. To overcome theseambiguities the Media Portal Cluster parameters override their equivalentsin the RTP Portal NE (see "Run-Time Service Configuration ParameterMapping" (page 86) for mapping of service configuration parameterlocations for service node variants).

You configure the BladeCenter T BCP 7200 by using a mix of data populatedin existing data structures (for example, the engineering parameters in theRTP Portal NE) and configuration parameters that reside in the MediaPortal Cluster data structure.

Following are the steps to configure the BladeCenter T BCP 7200, includingthe population of the data structures.

Procedure 22Configuring the BladeCenter T BCP 7200

Step Action


1 At this initial stage, all referenced data must be entered into thesystem.

Addresses: The structure of this data does not change. Enter allService IP addresses (physical and logical) into the Addresses datastructure so that they can be referenced by label. This data is usedby higher-level datafill to identify network nodes, network resources,and to establish operational presence in the required service-planes.

Figure 34Addresses list



.


2 External Nodes: This field is for datafill of static routes. It identifiesthose network nodes and network resources that require specialrouting considerations.

3 Gateways: The structure of this data does not change. Thisselection identifies those network resources that can perform routingfunctions. This information is used in the RTP Portals data structureto define the default route for the service node and to define staticroutes in separate datafill.

4 Subnet Masks: This selection defines the scope of anaddress-space. This information is used to scope the extent of theservice-planes in the Media Portal Cluster data structure and todefine static routes in separate datafill.

5 Static Routes: This selection is used for datafill of static routes anddefines the special routing considerations that need to be employedto access remote network nodes and network resources.

6 Enter data into the Interface1 field (pick-list of datafilled IPAddresses) with the intended physical IP address for eachBladeServer in the BladeCenter T chassis. This IP address is thebond0 physical address on the BladeServer and is also used torepresent the BladeServer and the BCP service instance to theMCS OAM framework.

Datafill Servers parameters. This stage of configuration creates alogical representation of a server within which to group togetherall the data that defines a physical service node including physicalIP address associations (the physical IP address bound duringinstallation and commissioning).

There must be a Server created for each service node (in otherwords, each hosting BladeCenter T BladeServer) so that it isadequately represented in the MCS OAM framework.

The structure of this data does not change.

7 First, open the Media Portal Cluster window within the NetworkElements and Media Portals navigation pane. Enter data into theMedia Portal Cluster entities. This stage of configuration creates alogical representation of the BCP Service (Clustered or Stand-Alone)within which to group together all the data that defines the service.

8 Next, click the Add (+) button to open the Add Media PortalClusterwindow to create a Service Cluster.

9 Enter a unique name for this Media Portal Cluster (for example,bctcluster1) and click Apply.



.


At this point the newly specified Cluster Name is associated witha default data structure and appears in the System ManagementConsole navigation tree.

10 The Media Portal Cluster can be populated with the parameters thatuniquely identify this cluster as well as all of the parameters thatdefine the service characteristics for this cluster.

11 Service Instances: Data must be supplied that specifies the uniquetraits of each active service instance and therefore the number ofBCP service instances in this cluster (in other words, an MPCPcontrol IP address, and up to two media IP addresses for eachService Instance). One entry exists in this data structure for eachService Instance. These constitute the "N" active service instancesin the N+1 fault-tolerance strategy (there is a single service instancedefined for both 1+0 standalone and 1+0 service clusters).

The numbers in Media Portal Cluster: Service Instances Datafillcorrespond to steps a through e, that follow.

Figure 35Media Portal Cluster: Service Instances Datafill

a. Click the Service Instances data structure to open the ServiceInstances window for this Service Cluster.

b. Click the Add (+) button to open the Add MPCluster ServiceInstances window.



.


c. Define the Service Instance for this Service Cluster:

• Service ID: unique value (0-6) for each Service Instance in aService Cluster.

• Control IPAddr SubnetMask: a pick-list of the Subnet Masksdefined in this site that scopes the extent of the Control-plane.

• Net1 Media IPAddr SubnetMask: a pick-list of the SubnetMasks defined in this site that scopes the extent of theMedia-plane to which this interface is connected.

• Net2 Media IPAddr SubnetMask: a pick-list of the SubnetMasks defined in this site that scopes the extent of theMedia-plane to which this interface is connected.

• Control IPAddr: a pick-list of the Addresses defined in thissite that identifies the point of presence that this ServiceInstance occupies in the Control-plane.

• Net1 Media IPAddr: a pick-list of the Addresses defined inthis site that identifies one of the points of presence that thisService Instance occupies in the Media-plane.

• Net2 Media IPAddr: a pick-list of the Addresses defined inthis site that identifies one of the points of presence that thisService 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 ofService Instances to this Service Cluster.

12 Configuration Parameters: These are data parameters that definethe operating service context shared by all service instances (allservice instances in a cluster run the same service configuration tomaintain service consistency).

The numbers in Media Portal Cluster: Configuration ParametersDatafill correspond to substeps a through d, following.



.


Figure 36Media Portal Cluster: Configuration Parameters Datafill

a. Click the Configuration Parameters data structure to open theConfiguration Parameters window for this Service Cluster.

b. Click the Add (+) button for new, or the Change (-/+) button forexisting, to open the Add MPCluster Config Parameters windowor the Edit MPCluster Config Parameters window.

c. Define the new configuration parameters for this Service Cluster(see Media Portal Cluster: Data Structures for a description ofeach parameter).


13 Fault tolerance: Data supplied to define the characteristics of thechannel used for intracluster communication between all clustermembers.

The numbers in Media Portal Cluster: Fault Tolerance datafillcorrespond to substeps a through d, following.



.


Figure 37Media Portal Cluster: Fault Tolerance datafill

a. Click the Fault Tolerance data structure to open the FaultTolerance window for this Service Cluster.

b. Click the Add (+) button for new, or the Change (+/-) button forexisting, to open the Add MPCluster Fault Tolerance window orthe Edit MPCluster Fault Tolerance window.

c. Define the new fault-tolerance parameters that define thePeering-plane intracluster communications channel for thisService Cluster (see Media Portal Cluster: Data Structures for adescription of each parameter).


14 Static Routes: Provides a convenient interface for defining staticroutes for the BladeCenter T BCP (see Figure 38 "Media PortalCluster: Static Routes Datafill" (page 105) for more information).

The numbers in Figure 38 "Media Portal Cluster: Static RoutesDatafill" (page 105) correspond to substeps a through d, following.



.


Figure 38Media Portal Cluster: Static Routes Datafill

a. Click the Static Routes data structure to open the Static Routeswindow for this Service Cluster.

b. Click the Add (+) button to open the Add MPCluster StaticRoutes window.

c. Select one of the static routes defined in this site using thepick-list: (see


e. Repeat this data to add as many static routes to this BladeCenterT BCP as it needs to provide service.

15 Session Managers: (see Figure 39 "Media Portal Cluster: SessionManagers datafill" (page 106)) Call Server Data that identifies theset of SIP Session Managers to which the BCP Service Cluster mustadvertise its availability to provide service (in other words, establishMPCP control sessions).

The numbers in Figure 39 "Media Portal Cluster: Session Managersdatafill" (page 106) correspond to substeps a through e, following.



.


Figure 39Media Portal Cluster: Session Managers datafill

a. Click the Session Managers data structure to open the SessionManagers window for this Service Cluster.

Figure 40bctcluster1 Session Managers dialog box

b. Click the Add (+) button to open the Add Session Managerwindow.

c. Specify the following:

• Session Manager: Select one of the Session Managersdefined in this site using the pick-list.

• Discovery Probe Timer Period: Specify the frequency atwhich the BCP service instances advertise their availabilityto provide service to this Session Manager.




.


e. Repeat this data to add as many Session Managers asnecessary to this BladeCenter T BCP. There can be a maximumcombined total of 20 Session Managers and Gateway Controllersassociated with a BCP.

16 Gateway Controllers: (see Figure 41 "Media Portal Cluster: GatewayControllers datafill" (page 107)) Call Server data identifies the setof CS 2000 Gateway Controllers to which the BCP Service Clustermust advertise its availability to provide service (to establish MPCPcontrol sessions).

The numbers in Figure 41 "Media Portal Cluster: GatewayControllers datafill" (page 107) correspond to substeps a throughe, following.

Figure 41Media Portal Cluster: Gateway Controllers datafill

a. Click the Gateway Controllers data structure to open theGateway Controllers window for this Service Cluster.

b. Click the Add (+) button to open the Add Gateway Controllerwindow.

c. Specify the following:

• Gateway Controller: Select one of the Gateway Controllersdefined in this site using the pick-list.



.


• Discovery Probe Timer Period: Specify the frequency atwhich the BCP service instances advertise their availabilityto provide service to this Gateway Controller.


e. Repeat this data to add as many Gateway Controllers asnecessary to this BladeCenter T BCP. There can be a maximumcombined total of 20 Session Managers and Gateway Controllersassociated with a BCP.

17 Enter data for the RTP Portals Network Elements.

The RTP Portals Network Element remains the fundamentalconfiguration data structure for representing the hardware platform.The RTP Portals Network Element provides the BladeCenter TBCP with service node configuration data (for example, Engineeringparameters) and a point of attachment into the MCS OAMFramework. It is the RTP Portal NE that enables the deploymentof the BCP software, provides the channel for telemetry (Logs,Alarms, and Operational Measurements), and enables support formaintenance actions (Start, Stop, and Kill).

In the context of the BladeCenter T BCP, each RTP Portals NetworkElement (BladeServer) represents a possible service node onwhich a BCP service instance can execute. The association of aBladeCenter T service node to the BCP Service is made through thenew MPCluster name field that is added to the RTP Portal NE data.After the association between service node and service is made, theBCP service instances can execute on the associated RTP PortalNEs and float across the RTP Portal NEs to preserve service asfaults occur.

To specify a RTP Portal NEs membership in a BladeCenter T BCPService Cluster, the following steps must be taken (see Figure 42"RTP Portal NE: Association of MP Cluster Membership" (page109)).

The numbers in Figure 42 "RTP Portal NE: Association of MPCluster Membership" (page 109) correspond to substeps a throughe, following.



.


Figure 42RTP Portal NE: Association of MP Cluster Membership

a. First, open the RTP Portals window within the Network Elementsor Media Portals navigation pane.

b. Click the Add (+) button to open the Add RTP Portal windowto create a new service node.

c. The only consideration after creating a BladeCenter T RTP PortalNE is the MPCluster name field used to associate a servicenode with the BCP service.

The RTP Portal NE MP Cluster field is populated by selectingentries from a pick list. The pick list contains an entry for eachof the Media Portal Cluster defined in the Network Data. Eachserver participating in a Service Cluster (identified within theRTP Portals Network Element data structure) is assigned Clustermembership in this manner, thereby establishing a commonassociation among the N+1 servers hosting the Cluster.

Cluster membership is available only to the BladeCenter T BCP7200.

You must configure both of the supported BladeCenter T BCPconfigurations (the Stand-alone and the Service Cluster) asmembers of a Cluster. In the case of the BladeCenter T BCPStand-alone, configuration is performed such that a 1+0 (1 Active



.


Service Instance and 0 Standby Service Instances) cluster iscreated. All Clusters are uniquely defined by the combinationof a multicast IP Address and a multicast port specified in thefault-tolerance Data in the new Media Portal Cluster NetworkData. However, what makes the Stand-Alone configurationunique in that only one Service Instance is configured.

The BladeCenter T BCP fails to start if it detects MPClustername=<none> in its datafill.

d. In the Management Consoles navigation pane, click Apply tocreate an instance of the RTP Portal NE data (for this servicenode).

e. Populate the RTP Portal NE data structures.

The only new considerations that come into play after populatingthe BladeCenter T RTP Portal NE data structures are:

• The Service Instance IP address provides the point ofpresence in the Management-plane (a separate IP address isspecified in the Media Portal Cluster that provides presencein the Control-plane).

• The redundancy of the service-level configuration parametersthat still reside in the RTP Portal NE but are not used by theBladeCenter T as they are superseded (for the BladeCenterT) by equivalent parameters present in the Media PortalCluster datafill. See the Table 2 "Service configurationparameters for the BladeCenter T" (page 86) for mapping ofthese parameters for each service node variant.

You can repeat this process up to eight times to providesufficient service nodes to support execution of seven activeservice instances and one standby service instance) toadd the desired number of Service Node associations to aService Cluster.

Due to complex data dependencies, after an association ismade between a service node and a Service Cluster (or<none>) as occurs after the BCP datafill is committed, theonly means of changing the association is through removaland recreation of the RTP Portal NE.

—End—



.


BladeCenter T BCP service creationThe following activities must be performed to prepare and deploy theBladeCenter T BCP and to actively provide service in the network:

• Installation and commissioning of the base hardware (IBM BladeCenterT) and software (Red Hat ES 3) platforms. This ensures proper setup ofsuch items as hardware, cabling, network connectivity, and IP addressassignments.

• Configuration of both the BCP Service (Media Portal Cluster data) andthe BCP service node (RTP Portals).

• Deployment of the service software to distribute the service logic to eachof the BladeServers participating in the Service Cluster.

• The Service Instance must be started transitively (the START commandmust be issued from the System Management Console on each of theRTP Portal NEs that are members of the service cluster) for instantiationto 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 ServiceCluster configurations, but each is described separately for completeness.

Stand-alone creationThis section describes the deployment of Service software and the startupof the BCP service for a Stand-Alone BladeCenter T BCP service instance.

The Stand-Alone BCP Service is a single nonredundant instance of theservice that runs independently of all other instances. Even though theStand-Alone BCP Instance is operationally different from the BCP ServiceCluster in a number of ways, it is configured as if it were a 1+0 non-redundantCluster. That is, one active service instance and zero standby instances.

The Stand-Alone Service Instance is configured only with one element ofService Instance Data (in Network Data => Media Portal Cluster). Thecharacteristics that distinguish a Stand-Alone BCP Instance from a BCPService Cluster, specifically a 1+0 fault-tolerant Service Cluster (which isalso configured with a single active service instance), are

• the setting of the Stand Alone (Boolean) parameter in the MediaPortal Cluster Fault Tolerance data. After the Stand Alone Booleanis configured, it causes a nonredundant 1+0 (a single active ServiceInstance and no Standby Service Instance) cluster to form.

• the number of associated RTP Portal NEs. A nonredundant 1+0 clusteris associated only with a single service node; a fault-tolerant 1+0 servicecluster is associated with two service nodes.



.


After this configuration is instantiated, it effectively creates a one-to-oneassociation of the Stand-Alone BCP service instance with the targetBladeServer. A single BladeCenter T chassis can host up to eight separateStand-Alone BCP Instances, one on each of the available BladeServersin the BladeCenter T chassis (see Figure 43 "Stand-Alone BCP serviceinstances (Logical View)" (page 112)).

Figure 43Stand-Alone BCP service instances (Logical View)

You perform the following activities in the course of introducing a newStand-Alone BladeCenter T BCP service instance into a site:

• Installation and commissioning of the base hardware and softwareplatforms.

• Configuration of the service. You can change the BCP Serviceconfiguration at any time, but is picked up only by the service after theRTP Portal NE is started. The key piece of configuration informationthat distinguishes the 1+0 Stand-Alone Service from the 1+0 redundantService Cluster is the setting of the Stand Alone configuration parameterin the Media Portal Cluster Fault Tolerance data.



.


Procedure 23Creating the service

Step Action


1 Navigate to the RTP Portals folder in the navigation pane.

2 Create an RTP Portal NE representing the BladeServer targeted toparticipate in this 1+0 Service Cluster (this is the only RTP Portal NEassociated with this Cluster, making it a standalone).

3 Open the NE Maintenance window and click Deploy to dispatch theservice software to the BladeServer.

After an association is made between an RTP Portal NE and aService Cluster, the only way to change the association is throughdeletion and recreation of the RTP Portal NE.


4 After the Service Instance is successfully deployed, it must bestarted so that instantiation of the run-time structures occurs andthe service can be offered.

Navigate to the RTP Portals Network Element representing theBladeServer participating in this 1+0 Service Cluster.

5 Open the NE Maintenance window and click Start to start up a BCPservice instance on this BladeServer.

—End—



.


Figure 45Starting NE Maintenance

As the BCP service instance on the target BladeServer comes into service,it retrieves its configuration data from the MCS Database Server. The BCPservice instance determines that it is configured to participate in a Clusterand then locates the specific Cluster configuration (Media Portal Clusterdata). Instantiation of the service proceeds using the Media Portal ClusterData to configure the service.

Some of the first processes started by the BCP service instance are thosethat support the N+1 fault-tolerant framework (for example, they allocate theconfigured multicast address and port, and start the reliable messagingframework to open the intracluster communications channel). As the N+1fault-tolerant Framework Processes come up, they establish the Cluster inrun-time. Since this is the first BCP service instance in the Cluster, it isdetermined to be an active instance. In fact, since this is a Stand-Aloneconfiguration, this is the only instance.

After a BCP service instance is configured as active state, it issues MPCPRSIP messages to all of its configured Call Controllers (the SessionManagers and the Gateway Controllers as configured in the Media PortalCluster Data) to advertise its ability to provide service. At this point, you cancall upon the BCP service instance to service calls.



.


Figure 46BladeCenter T BCP 7200 standalone service deployment

Service Cluster InstantiationThis section describes the deployment of service software and the startupof the BCP service for a BladeCenter T BCP 7200 fault-tolerant ServiceCluster. The deployment phase places the service software on the targetBladeServers, and the start phase causes the instantiation of run-timestructures so that the BCP Service Cluster forms and begins to activelyprovide service.

The BCP Service Cluster is an N+1 (N active Service Instances, and 1standby Service Instance) redundant collection of BCP service instances.Each instance of the BCP Service that runs in the Cluster coordinates itsactivities with the other member instances. Service coordination takes placeover the intracluster communications channel (the Reliable MessagingFramework) that is used to form (using the Election Protocol) and maintainthe Cluster (using the Checkpointing functions).

When forming an N+1 Cluster, it is always the final instance joining theCluster that becomes the standby instance. This ensures that a Clusterbegins to provide service as soon as it is started and grows to engineeredoperational capacity as quickly as possible before electing a standbyinstance.

The run-time characteristic that distinguishes the BCP Service Cluster froma Stand-Alone BCP service instance is that a Service Cluster is usuallyconfigured 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 isconfigured much like a 1+0 standalone service instance, except for thesetting of the standalone configuration parameter in the cluster data.The 1+1 fault-tolerant service cluster is also distinguished from the 1+0standalone service by the fact that it contains an active service instance thatcheckpoints its data to a standby service instance, which is available to takeover 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. Aone-to-one relationship between the Service Instances and the servicenodes does not exist.

A single BladeCenter T chassis can host a BCP Service Cluster of up to7+1: seven active BCP service instances and one standby BCP serviceinstance (see Figure 47 "BladeCenter T BCP Service Cluster (LogicalView)" (page 116)).

Figure 47BladeCenter T BCP Service Cluster (Logical View)



.


The following activities are performed in the course of introducing a newBCP Service Cluster into a site:

• installation and commissioning of the base hardware and softwareplatforms

• configuration of the service and the service nodes. You can change theBCP Service configuration at any time but (for the most part) is pickedup only by the service on startup.

Procedure 24Instantiating the service cluster

Step Action


1 Navigate to the RTP Portals Network Elements representing eachof the BladeServers that participate in this (1+0) Service Cluster(a sample 1+0 fault-tolerant Service Cluster is presented fordemonstration purposes).

2 For each of these RTP Portal NEs ( two RTP Portal NEs arerequired to form a 1+0 fault-tolerant Service Cluster), open the NEMaintenance window and click Deploy to dispatch the Servicesoftware to the associated BladeServer.


3 After the member Service Instances are successfully deployed, theymust be started individually so that instantiation of the run-timestructures occurs, the Cluster forms, and service can be offered.Start up of individual Service Instances occur any time after theservice software is deployed to the BladeServers participating in theCluster. This process is repeated for each of the RTP Portal NEsrepresenting a member of the Cluster.

Navigate to the RTP Portals Network Element representing aBladeServer participating in this 1+0 Service Cluster.



.



5 Click Start to start up a BCP service instance on this BladeServer.

Issuing the Start command to the RTP Portal NE representing theother RTP Portal NE associated with this fault-tolerant ServiceCluster occurs in a similar fashion.

As the BCP service instance on the target BladeServer comes intoservice, it retrieves its configuration data from the MCS DatabaseServer. The BCP service instance determines that it is configured toparticipate in a Cluster and then locates the specific Media PortalCluster data. Instantiation proceeds using the Media Portal Clusterdata to configure the service.

The other BCP service instance starts up in a similar fashion.

Some of the first processes started by the BCP service instanceare those that support the N+1 fault-tolerant Framework (forexample, they allocate the configured multicast address and port,and start the reliable messaging framework to open the intraclustercommunications channel). Since this is the first BCP serviceinstance in the 1+0 Cluster, it is determined by the N+1 fault-tolerantframework to be an active instance.

As the second BCP Instance starts up and joins the Cluster, the N+1fault-tolerant framework determines that since this is configured as a1+0 Cluster, this instance must be the Standby. This second BCPInstance operates in Standby mode, checkpointing all service datafrom the active Service Instance and monitoring its status, whilewaiting for the opportunity to assume activity in the event that theactive Service Instance encounters a fault.

After a BCP service instance is configured as active, it issues MPCPRSIP messages to all of its configured Call Controllers (SessionManagers and Gateway Controllers as configured in the MediaPortal Cluster data) to advertise its ability to provide service.

After this point, the Cluster comes into service, and the activeBCP service instance is called on to service calls. In the courseof processing service requests, all active BCP service instancescommunicate inside the Cluster to checkpoint service data to theStandby Service Instance and to convey status so that the Clusterremains synchronized and able to survive the failure of one of itsmembers.

—End—



.

Troubleshooting the IBM BladeCenter hardware 119

Troubleshooting the IBM BladeCenter hardware

This chapter describes the troubleshooting of BladeCenter hardwareproblems.

IBM BladeCenter hardware failure and replacement

ATTENTIONIf any support or warranty contracts exist on the equipment, Nortel recommendsthat you use these support agreements to replace the hardware that is identifiedas failed. If you do not use those agreements, you can void the remaining timeon the support agreements.

BladeCenter modulesThe general steps for physically removing and installing these modules arethe same (The blower modules are somewhat different. See the"Blowermodules" (page 121))

CAUTIONMake sure you have the replacement on hand before removing anymodules (including such items as the blower and the managementmodule). If they are removed and not replaced immediately theair flow causes the chassis and other components to overheatand become damaged.

Procedure 25Removing a module

Step Action

At the bay,

1 Pull down on the orange release lever until it stops. This slides themodule out of its bay approximately half an inch.

2 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 Slide the module into its bay until it stops.

3 Push the release lever closed. Additional instructions specific to aparticular module are provided as needed.

—End—

Procedure 26Replacing management modules

Step Action

At the bay,

1 To replace an existing management module, make sure all existingsessions (for example, web or telnet) to the management moduleare shut down.

2 Unplug the KVM and network cables from the management module.

3 Remove the existing management module from its bay.

4 Install the new management module.

5 Reconnect the KVM and network cables to the new managementmodule.

6 Ensure that the OK LED on the back plate of the module is lit.

7 To configure the new management module, contact your next levelof support.

It is necessary to only configure the primary management module(for example, with IP addresses); the secondary managementmodule does not need to be explicitly configured. In the event thatthe primary management module fails, the secondary managementmodule automatically inherits the settings from the primarymanagement module. It is necessary that both managementmodules are connected to the same network subnet.

—End—

Procedure 27Replacing an existing ESM (I/O module)

Step Action

At the bay,



.


1 Unplug the network cables from the I/O module.

2 Remove the existing I/O module from its bay.

3 Install the new I/O module.

4 Reconnect the network cables to the new I/O module.

5 Ensure that the OK LED on the back plate of the module is lit.

6 Contact your next level of support to configure the new I/O module.

—End—

Procedure 28Replacing power supply modules

Step Action

At the bay,

1 Unplug the power cable from the power module.

2 Remove the existing power module from the bay.

3 Install the new power module.

4 Reconnect the power cable to the new power module.

5 Ensure that the other end of the power cable is connected to a 220VPDU or 220V AC power outlet.

6 Ensure that the DC and AC power LEDs on the back plate of themodule are lit.

—End—

Blower modulesThe procedure for removing and installing a blower module is slightlydifferent (in the release mechanism) than the other BladeCenter modules.If you replace an in-service blower module, replace it within two minutesduring service.

Procedure 29Removing a blower module

Step Action

At the bay,



.


1 Press the orange release button on the blower module handle.

2 Grab the handle and slide the module completely out of its bay.

—End—

Procedure 30Installing a blower module

Step Action

At the bay,

1 To install a blower module, slide the blower module into its bay untilthe release button clicks.

—End—

BladeServers (x-blade)

Procedure 31Replacing an existing single-slot blade (or the processor half of adual-slotblade)

Step Action

At the bay,

1 Shut down the BladeServer operating system.

2 Power down the BladeServer by pressing the white power-controlbutton for the blade (located behind the control panel door onthe front of the blade; the panel door flips down to expose thepower-control button).

3 Wait about 30 seconds to let the drives on the blade spin down.

4 Open (pull apart) the two release levers until they stop. This slidesthe blade out of its bay about half an inch.

5 Grab the body of the blade and slide it completely out of its bay.(Note that the spring-loaded doors cover the empty bay automaticallyafter the blade is removed.)

6 Make sure the release levers on the new BladeServer are fully open.

7 Slide the new BladeServer into its bay until it stops. (Note that thespring-loaded cover doors push out of the way as you slide the newBladeServer into place.)



.


8 Push the release levers on the new blade fully closed.

9 Power up the new BladeServer by pressing the power-control buttonfor the blade.

10 Ensure that the green power LED on the front panel of the blade is litsteadily; a blinking LED means that the blade is not powered up.

11 Configure 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 ofan existing dual-slot blade, see "Replacing the SCSI drive" (page 123).

Replacing the SCSI driveThe expansion half of a dual-slot blade contains up to two hot-swappableSCSI drive trays that you can replace without having to power down theblade itself.

Procedure 32Replacing the SCSI drive

Step Action

At the bay,

1 To replace an existing SCSI drive, make sure that the drive is spundown (stopped spinning).

2 Slide the drive tray out of its bay.

3 Ensure that the tray release handle for the new drive tray is fullyopen.

4 Install the new drive tray into its bay.

5 Push the tray release handle down until it is fully closed.

6 Verify that the green hard disk activity LED is flashing, indicatingthat the drive is accessed.

If Redundant Array of Inexpensive Disks (RAID) is configured forthis drive, the new drive is automatically rebuilt upon insertion. Thesystem continues to run while the rebuild occurs. To check the status



.


of the rebuild, run /usr/local/bin/getScsiInfo. This tells you how muchof the rebuild is complete and how much is left. Depending on thesize of the drive, the rebuild can take a few hours to complete.

—End—

BladeCenter chassis

Procedure 33Replacing the BladeCenter chassis

Step Action

At the bay,

1 If the chassis itself must be replaced, shut down and remove theBladeServer blades and expansion units.

2 Power down the BladeCenter by disconnecting the power cablesfrom the power modules.

3 Remove all cables connected to the BladeCenter modules.

4 Remove the modules (management and I/O) from their respectivebays.

5 On the back panel of the BladeCenter chassis, disengage theshipping brackets (located about halfway down on either side of theback panel) by sliding them inwards, towards the blower modulebays.

6 Unscrew the thumbscrews located at the bottom corners of the backpanel, and then pull them up and out until the chassis slides outabout half an inch.

7 Grab the chassis body and slide the chassis out about halfway.

8 While supporting the chassis, disengage the release levers on thesides of the chassis and then pull the chassis the remainder of theway out.

To install a new chassis, reverse the preceding steps.

—End—



.

125

Accounting management

Functional descriptionThe BCP 7200 does not perform accounting management. However, anindication that a BCP 7200 component is used during a session is providedin the accounting records.

For more information about accounting, see Accounting ManagerFundamentals (NN42020-144).



.

126 Accounting management



.

127

Performance management

The HALayer OM Group supports the BladeCenter T BCP. This OM Groupconsists of the following in-band performance measurements:

• statusCnt—Meter showing the number of internal status change eventsgenerated by the fault-tolerance mechanisms on this service node.)

• updateCnt—Meter showing the number of service instances that join thecluster from the perspective of this service node.)

• chkPointsRcvd—Meter showing the number of checkpoints received bythis service node.)

• chkPointsSent—Meter showing the number of checkpoints sent by thisservice node.)

• activeInstances—Meter showing the number of active services instancesin the service cluster associated with this service node.)

• standbyInstances—Meter showing the number of standby serviceinstances in the service cluster associated with this service node.)

You can monitor BCP 7200 performance through the System ManagementConsole by viewing Operational Measurements (OMs). For moreinformation about BCP 7200 OMs and the viewing of these OMs, see theSystem Management Console User Guide (NN42020-110). OMs providestatistical information about the server operations and performance. OMsare represented in terms of groups, which contain registers (counters andgauges) that provide performance-related data.

The System Manager scans OM Group registers at a configured interval.Administrators can view the OM information associated with a selectedcomponent in the OM Browser at any selected point in time (correspondingto the launching of the OM Browser). Configure the OM scan cycle using theOAM configuration options available in the System Management Console.

Two types of OMs exist: active and holding. Active OMs are displayed asthey are reported by the server to the Management Server/ManagementConsole. Holding OMs are already archived to files on the server hostingthe active System Manager.



.

128 Performance management

Viewing operational measurementsBoth the active and holding OM on the System Manager are viewed in theSystem Management Console OM browser. For information about using thebrowsers, see System Management Console User Guide (NN42020-110).The information listed in the following table appears in the OM browser.

Table 4OM details displayed in the OM browser

Information Description

Group Name The name of the OM group where the scanned information resides.

TimeStamp The instance the OM information is scanned.

InstanceName The name of the service originating the OM information.

Register Name The name of the OM register at the time of the scan.

Register Value The value of the OM register at the time of the scan.

BCP 7200 OMsThe BCP 7200 generates the OMs described in Table 5 "BCP 7200 generalOMs" (page 128). Additional OMs related to the use of the BCP 7200are pegged by the Session Manager. For more information about thiscomponent, see Operational Measurements Reference (NN42020-704).

Table 5BCP 7200 general OMs

OM Name Format Definition

Go Online Count Integer Counter tracking the number of times the BCP 7200 iscommanded to an online state. The online state can becommanded through the System Management Consoleor it can be auto recovered from a service-denyingalarm.

Denied Service Integer Counter indicating number of times service is deniedthrough the BCP 7200 due to problems or lack ofresources.

Received CreateConnection Count

Integer Counter indicating number of create connectionmessages received.

Processed CreateConnection Count

Integer Counter indicating number of create connectionmessages processed.

Received DeleteConnection Count

Integer Counter indicating number of delete connectionmessages received.

Processed DeleteConnection Count

Integer Counter indicating number of delete connectionmessages processed.

Received ModifyConnection Count

Integer Counter indicating number of modify connectionmessages received.



.

BCP 7200 OMs 129


Processed ModifyConnection Count

Integer Counter indicating number of modify connectionmessages processed.

Received Response Count Integer Counter, tracks the number of response messagesreceived

Processed ResponseCount

Integer Counter that tracks the number of response messagesprocessed

RSIP Count Integer Counter that tracks the number of RSIP message sent.

Retransmit Count Integer Counter that tracks the number of messagesretransmitted.

Audit Cycle SequenceIDCount

Integer Counter that tracks the number of audit cycles whichoccur.

Total Number ConnectionsRemoved Count

Integer Counter that tracks the total number of connectionsremoved across all audit cycles.

ConnsRemovedLatestCycle

Integer Counter that tracks the total number of connectionsremoved (recovered) by the latest idle stream auditcycle.

RTPMPPortUsageMeter Integer Meter showing number of ports in use.

RTPMPAvailableBladesMeter

Integer Meter showing number of blades available to provideservice.

RTPMPActiveBladesMeter Integer Meter showing number of blades with activeconnections.

NumEntriesInConnMapMeter

Integer Meter showing the number of connections in the hostCPU connection map.

PreExistingConnections Integer Meter showing the total number of connections that theHost CPU finds during host recovery.

RecoveryModeFailures Integer Meter showing the number of media blades to whichcontrol cannot be reestablished during host recovery.

NumConnsRecovered Integer Meter showing total number of connectionsreconstructed during the last host recovery action.

<bladex>RecoveryPreExistingConns

Integer Meter showing the number of connections discoveredduring the last blade recovery action.

<bladex>RecoveryNumConnsRecovered

Integer Meter showing the number of connections reconstructedduring the last blade recovery action.



.

130 Performance management

• OMs generated by the Session Manager for the BCP 7200 are listed inTable 6 "Session Manager OM group Media Portal" (page 130).

Table 6Session Manager OM group Media Portal


MediaPortalSelectedFromDefaultPoolCount

Integer BladeUDPIOControllerFactory: Each time aBCP 7200 is selected from the default resourcepool, this OM counter is incremented.

MediaPortalResourceUnavailableCount

Integer BladeUDPIOControllerFactory: Each time aBCP 7200 is inserted but has no resourceavailable, this OM counter is incremented.

MediaPortalInsertedCallCount Integer BladeUDPIOControllerFactory: Each time aBCP 7200 is inserted for a call, this OM counteris incremented.

MediaPortalSelectedFromGroupCount

Integer BladeUDPIOControllerFactory: Each time aBCP 7200 is selected from a Media PortalGroup, this OM counter is incremented.

CreateConnectionCount Integer Tracks the number of Create Connectionrequests.

DeleteConnectionCount Integer Tracks the number of Delete Connectionrequests.

Modify ConnectionCount Integer Tracks the number of Modify Connectionrequests.

DisableConnectionCount Integer Tracks the number of Disable Connectionrequests.

ResponseReceivedCount Integer Tracks the number of response messagesreceived.

RSipReceivedCount Integer Tracks the number of RSip messages received.



.

131

Security and administration


• "Security overview" (page 131)

— "Network-level security functions" (page 131)

— "BCP 7200 component-level security functions" (page 132)

• "User administration" (page 133)

Security overviewOne function of the BCP 7200 is to secure the media interface to the MCSServices Network. The securing of the media layer is achieved througha combination of methods at the network level and the component (BCP7200) level.

Network-level security functionsAt the network level, media layer security is achieved by the randomizationof the IP addresses/ports used for multimedia sessions and use of NAPT(Network Address Port Translation) technology to obscure the networktopology of the MCS Services Network.

Media Blade (IP address) randomizationAfter a multimedia session requests resources, the BCP 7200 selectsan appropriate media blade to host the session. Media blade selectiondetermines the specific IP address that is made available to the mediastreams for the session.

During the selection of a media blade, the port usage of each availablemedia blade is queried to determine the number of available ports for each.The media blade that has the most available ports is selected. This methodof selection provides randomization and helps distribute the session loadacross the media blades.



.

132 Security and administration

Port randomizationAfter the BCP 7200 is deployed, each media blade is configured with a poolof ports containing a specific number of ports in a specific range basedon configuration data (Number Ports, Min Port Value, Max Port Value,respectively).

As multimedia sessions are initiated, a port is chosen from the port poolassociated with the selected media blade. For nonstatic port configurations(Static RTP Ports is configured to be false), after a multimedia sessionis complete, associated ports are deallocated from the pool, and newreplacement ports are allocated to the pool. The deallocation of used portsand allocation of replacement ports provides randomization in the port poolsfor the media blades.

NAPT functionTo obscure the network topology, the BCP 7200 uses the NAPT functionalityto secure the multimedia sessions so that topology information does notleak.

Multimedia sessions are secured by maintaining a list of media ports (NAPTtable) that are in use within active multimedia sessions. Only packetsthat arrive on these active ports are processed. Packets which arrive onnonactive ports are rejected.

BCP 7200 component-level security functionsThe BCP 7200 component also contributes to system security by openingand closing media ports only in response to requests from the SessionManager and by rejecting any unauthorized packets that arrive on an activeconnection.

Authenticated requestsAll requests to manipulate the media resources on the BCP 7200 originatefrom the Session Manager. The Session Manager ensures that all requestsare made by, or made to, a valid service subscriber. In this way, the SessionManager effectively authenticates all requests.

In addition, the portion of the BCP 7200 that processes these requests tomanipulate the media resources resides safely within the network.

Packet filter or firewallAs packets are received, the BCP 7200 analyzes each packet to ensurethe following:

• The data format is RTP/RTCP/UDP, as indicated by the sessiondescription. All other packet types are discarded.



.

User administration 133

• The source or destination addresses match the expected source ordestination addresses indicated in the session description. Packets thatdo not have a matching source or destination address are discarded.

• The source or destination ports match the expected source ordestination ports indicated in the session description. Packets that donot have a matching source or destination port are discarded.

User administrationBasic administrative tasks for the BCP 7200 are covered in the Upgrade,Configuration, and Fault sections of this document. Other basicadministrative tasks related to the System Management Console arecovered in the System Management Console User Guide (NN42020-110).

The BladeCenter T BCP service is managed through the member RTPPortal NEs. It is through manipulation of the state of the RTP Portal NEsthat the BladeCenter T BCP service can be transitively brought into, andout of, service. Administrators basically manage the clusters by managingthe network elements.

Table 7 "BCP 7200 service management command reference" (page 133)contains a detailed explanation of the transitive service management. Inthis table, Initial Active is the first service node to host an active serviceinstance. N+0 is the state of the service cluster if a standby service instancedoes not exist (as is the case when the service cluster is coming intoservice, the service cluster is operating in failure-mode, or when the servicecluster is being removed from service). N+1 is the state of a fully-formedand fault-tolerant service cluster (as is the case if the service cluster isoperating with all active service instances providing service and a standbyservice instance that is ready-and-able to support takeover of any failedactive service instance).

Table 7BCP 7200 service management command reference

BladeCenter T

N+1 redundant service cluster (target server/instance)

Initialactive

N+0(active)

N+1(active)

N+0(standby)

N+1(standby) Last active

Start

Beginprovidingservice withfirst activeinstance.

Expandservicecapacity withnew activeinstances.

n/a Bring standby instanceinto service.Establishclusterredundancy

n/a n/a



.


BladeCenter T

N+1 redundant service cluster (target server/instance)

Initialactive

N+0(active)

N+1(active)

N+0(standby)

N+1(standby) Last active

Stop

Gracefulshutdown:finish processing existingsessions,no newsessionsestablished.

Gracefulshutdown:finish processing existingsessions, nonew sessionsestablished.

Gracefulshutdown:finish processing existingsessions,no newsessionsestablished.

n/a Acquiesce:Stop providingservice.Cluster losesredundancy.

Gracefulshutdown:finish processing existingsessions, nonew sessionsestablished.

No takeover. No takeover. No takeover. No takeover.

Kill

Hard stop:Stop providing all serviceimmediately;clear allsessions.



n/a Hard stop:Stop providingserviceimmediately.

Hard stop:Stop providingall serviceimmediately;clear allsessions.

No takeover(no standbyserviceinstance)

Takeoveroccurs. Thisactive serviceinstance andall hostedsessionsbegin runningon thestandby. TheCluster losesredundancy.

The Clusterloses redundancy.

No takeover(no standbyserviceinstance)

Stand-alone managementManage the Stand-alone BladeCenter T BCP (telemetry monitoring andstate changed) through the RTP Portal NE entity in the Nortel SystemManagement Console.

You can view Logs, Alarms, and Operational Measurements in theirrespective areas of the System Management Console.

Likewise, State Management (for example, Start, Stop, Kill commands) isperformed through the RTP Portal NE Instance window, which permits theservice to be transitively managed (see Figure 50 "BladeCenter-T BCPStand-alone service management system" (page 136)).



.


Figure 49NE Maintenance commands



.


Figure 50BladeCenter T BCP Stand-alone service management system



.


Managing the Service ClusterManage a BladeCenter T BCP Service Cluster (telemetry monitoringand state changes) transitively through administrative coordination of themanagement functions of each individual RTP Portal NE participating in theCluster (for example, bct11 and bct12):

Figure 51NE Maintenance commands

Perform coordinated management of the collection of RTP Portal NEsassociated with the Cluster by using the Nortel System ManagementConsole. Logs, Alarms, and Operational Measurements are available foreach associated RTP Portal NE and are viewable in their respective areasof the System Management Console. Likewise, perform State Management(for example, Start, Stop, Kill commands) in a coordinated fashion on theRTP Portal NEs associated to the Service Cluster to achieve the desiredoperational result on the service. Each RTP Portal NE is managed usingthe NE Maintenance window of the RTP Portal NE.



.




.

139

BCT configuration worksheet

Successful configuration of the BCP depends on the accurate capture ofconfiguration information. The information that is required for provisioningthe BCP should be collected prior to installation. If you configure all eightBCPs on the BCT, you keep a record of eight individual slots (one for eachBCP, and each with its own set of attributes). The following table should becompleted before proceeding:

Table 8Information Required for Installation and Commissioning on the BCT platform

Border Control Point Configuration Information

Slot Attribute Example Value

Host card network address(Portal address)

47.104.10.145

Host card netmask 255.255.255.0

Host card default gateway 47.104.10.1

Host card IP failover active YES

Hostname RTP_04

Timezone US/Central

1

Timeserver IP address 47.103.18.2


47.104.10.146




Hostname RTP_04

Timezone US/Central

2




.

140 BCT configuration worksheet


47.104.10.147




Hostname RTP_04

Timezone US/Central

3



47.104.10.148




Hostname RTP_04

Timezone US/Central

4



47.104.10.149




Hostname RTP_04

Timezone US/Central

5



47.104.10.150




Hostname RTP_04

Timezone US/Central

6




.

BCT configuration worksheet 141


47.104.10.151




Hostname RTP_04

Timezone US/Central

7



47.104.10.152




Hostname RTP_04

Timezone US/Central

8




.

142 BCT configuration worksheet



.

143

Appendix ABackup and recovery


• "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

ATTENTIONBefore beginning any backup or restore operation involving the use of a remotetape device or remote file server, it is important to make sure that all nodesinvolved have their network interface configured to full-duplex mode. Thatincludes both the server backed up or restored, the tape or file server itself, andany intermediate nodes in the network being traversed. All MCS servers areconfigured to autonegotiate. Thus, if the nodes that the servers communicate withare configured to auto negotiate, they are configured to full-duplex. If a server(involved in the backup or restore) is not running at full-duplex, this results inbackup and restore times that are ten times normal.

The following prerequisites are required for a BCP 7200 tape backup orrestore:

• remote DDS4 or Universal Serial Bus (USB) tape drive. The tape drivedoes not need to be within the network, but it must be attached to amachine that is visible to the server conducting the backup.

• tape in the remote tape drive. For USB drives, use a 20-GB tape. ForSCSI 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 berunning at full duplex.

The following are required for disk backup:

• a disk with sufficient space for copying contents of the files stored underthe /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 connectedor disconnected.

• Type the command /etc/init.d/volmgt stop and press Enter.

• Connect or remove the USB tape drive. When connecting the tapedrive, 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 BCPThe time required for backing up the BCP can vary depending on networktraffic, remote operations, and the amount of data to be backed up. Threemethods for backing up the BCP exist:

• remote tape

• remote disk

• local disk

Setting up system access for backupAccess 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 isused and the telnet session dies, the associated process (backup in thiscase) dies as well.



.

Backing up the BCP 145

• a telnet session through a terminal server to the server serial consoleinterface.

Setting up the remote tape driveA remote tape drive is required. The following procedure outlines the stepsnecessary to properly configure the remote tape drive if it is on an MCSserver. Only DDS4 and USB tape drives are supported for backup andrestore of the BCP Linux servers. This server supports only backup andrestore from local disk.

If the remote tape drive is not on an MCS server, you can skip thisprocedure. However, you must ensure that the remote shell operations fromthe 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 (orthe sysadmin user). However, if you log on as root, the use of sudo must beremoved from the following commands.

Procedure 34Setting up the remote tape drive

Step Action

From the server

1 As the MCS server has to access the tape drive on the remote host,make sure it has the proper access to that host.

2 Log on as sysadmin to the remote host.

3 On the remote host, execute the following script, which enables theexecution of remote shell commands from the server being backedup (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 From the BCP 7200, log on as root.

5 Verify that access to the remote host is configured correctly:

rsh -l sysadmin <Tape_Server_IP> df -k <Enter>

where

<Tape_Server_IP> is the IP address of the remote host withthe tape drive.



.


6 Output appears on screen, indicating that the target system iscorrectly configured for the restore operation. If not, contact yournext line of support before continuing.

7 After the backup (or restore) procedure is complete, execute thefollowing command on the remote host to disable the execution ofremote shell commands on the remote host:

sudo /usr/local/bin/mcp_disable_remote_sh.pl

—End—

Backing up the BCPEnsure the remote tape drive is configured up correctly before proceedingwith tape backup to a remote host. For more information, see "Setting upthe remote tape drive" (page 145).

Procedure 35Backing up to a tape drive

Step Action

From a terminal server

1 Label the DDS4 tape with the BCP 7200 name and the date ofbackup.

2 Insert the tape into the tape drive of the server that acts as thebackup host.

3 Log on as sysadmin to the BCP 7200.

4 Type sudo /usr/local/bin/mcp_backup.pl <Enter>

5 The user is prompted for the type of backup. Enter a selection tocontinue:

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 backupPlease enter the number [1 to 4] of the type of backupto perform.

To back up to a remote tape, continue with the next step. For remotetape backup, proceed to step 9. For backup to a local disk, proceedto step 10.



.


6 Next, the user is asked for the IP address of the host where the tapedrive resides. Type the IP address and press Enter to continue. Themachine logical IP address, not the physical address, must be used.

7 Information regarding the remote tape drive appears, and the user isprompted to verify tape insertion. Verify the information and pressEnter to continue.

<timestamp> Backup to remote tape drive /dev/rmt/0cn onhost <Remote_Host_IP.<Remote_Host_IP> is alive.Please verify a tape is freshly inserted into the tapedrive.Any preexisting data on the tape is overwritten.Press Enter when you are ready.....

8 If the tape needs to be rewound, the user is prompted to rewind thetape as shown in the following example. Press Enter to accept theDefault (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 addressof the remote host:

Enter the IP address of the remote device (in dotnotation):

10 For Remote and Local Disk backups, the user is prompted for the fullpath and filename of the backup file:

Enter the path/filename to write the backup file to:

11 The backup operation can require several minutes to complete. Ifthe backup requires more than one tape, the system prompts theuser 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 thebackup is successful. The log file is stored in the directory/home/sysadmin/bkup_restore, and the filenameis mcp_backup.pl.log.<dayTimeStamp>. where<dayTimeStamp> is YYYY_MM_DD_HH:MM:SS.

13 Log off the machine.

14 From the remote host, disable remote access:



.


sudo /usr/local/bin/mcp_disable_remote_sh.pl <Enter>

15 Store the tape in a safe, cool, dry location.

—End—

Restore

ATTENTIONWhile restoring a BCP server from a backup, consider that the MCS backupprocedure only backs up configuration information in the /admin directory ratherthan the OS and its associated patches.

When a restore is applied, it is a reinstallation and the backup configuration datais restored afterwards. Since this is actually a fresh installation, the BCP patchesmust be applied after the installation. The /admin/portal.cfg file must be modifiedto include patchlevel=0 after the fresh installation and recovery using the VI editor.

Note that if the file is not modified, 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 configured up correctly before proceedingwith the restore. For more information, see "Setting up the remote tapedrive" (page 145).

Procedure 36Restoring the BCP 7200 from tape

Step Action

From the terminal server

1 Establish a terminal session to the host CPU through the terminalserver.

2 Insert the installation CD.

3 Reboot the system.

After the system boots from the installation CD, the initial welcomescreen appears.

4 Enter one of the following at the boot: prompt.

• serial-com1—Installation requires the COM1 serial port.

• serial-com2—Installation requires the COM2 serial port.serial-com2 is the required setting for a CPV5370 host CPU.

• kvm—Installation requires attached keyboard, monitor, andmouse.



.


Note that the selection determines the permanent location of thesystem console.

5 The software loads and checks for existing disk partitions. Thesystem will output results of the check and whether any partitionsare created and formatted. Press Enter to proceed.

6 The script presents the Configuration Data Selection screen.Select the third option.

7 The restore assumes that the default backup settings are used. Bydefault, the backup procedure backs up the /admin partition. Thispartition contains the configuration files. If some other partition isbacked up, the backup cannot be used to perform a restore.

8 The user is prompted for the restore type. Make the appropriateselection.

If restoring from tape, the script contacts the remote tape server. Ifthe tape is not rewound, the user is given the option to do so. Whenthe tape is ready, the script continues.

9 The script prompts the user for the IP address of the remotemachine. If restoring from a remote file, enter the filename. As thesystem restore overwrites any existing data, the script prompts forverification before beginning the operation.

10 The first phase of data configuration involves the followingnetwork-based items:

• Application type—A read-only value that is configuredautomatically by the installer and cannot be changed. Itdescribes the type of application being installed.

• Platform type—A read-only value that is configured automaticallyby the installer and cannot be changed. This value is configuredaccording to the hardware platform being configured.

• Hostname—The name given to the BCP 7200.

• Machine Logical IP—The IP address assigned to the BCP 7200.

• Default Gateway—The default gateway router assigned to theBCP 7200 host card.

• Netmask—The network mask for the BCP 7200 host card.

• Timezone—The timezone in which the BCP 7200 is physicallylocated.

• Host IP failover active—The true/false value that controls thehost IP failover service. If the service is active, the host carduses its network interfaces in an active/standby configuration.



.


11 You are prompted with a validation screen.

12 The second phase of data configuration involves the following itemsrelated to the media cards:

• Chassis Identify—A number that uniquely identifies the BCP7200 chassis. As a chassis can contain two independent MediaPorts, this value is specific to the chassis. The number must bebetween 0 and 255 inclusive. Do not assign the same chassisidentifier to multiple chasses on the same local network.

• Host card slot number—The slot number in which this host cardis located. It must be either seven, for side A of the chassis, ornine, for side B of the chassis.

• Media Blade Default Gateway—The gateway router that isassigned to each media card in the system. This IP address canbe different than the gateway IP assigned to the host card.

• Blade MAC Addresses—The MAC addresses for each mediacard in the system. Each card (NET1 and NET2) includes twoMAC addresses.

• NTP Clock Source—The IP address of an NTP server fromwhich the BCP 7200 obtains clock synchronization. There canbe zero or more configured NTP clock sources.

13 The user is prompted with a validation screen.

14 Next, the Date and Time Configuration screen appears. If the timeis correct, press Enter. Otherwise, press N to make correctionsusing the local time.

15 The user is prompted for passwords for root, nortel, and sysadmin.Passwords must be at least eight characters in length. The installerperforms a basic validation of passwords.

16 The script begins the restore. A progress indicator appears onscreen.

17 Next, the system is configured for specific BCP 7200 requirements.This step in the process takes approximately 5-10 minutes tocomplete.

18 The system reboots. Remove the CD-ROM from the drive when itis ejected.

19 As the system is powering on, hold down the F2 key to enter theBIOS setup. For security purposes, remove everything from theboot device list except the hard drive. Save and exit BIOS setup.The system reboots.



.


20 When the system reboot process is complete, press Enter to bootthe default image. After rebooting, the login prompt appears and theBCP 7200 is ready for software deployment.

—End—

Error scenariosThis section provides information regarding error scenarios that can occurwhen a backup or restore operation is in progress. For the BCP 7200, logfiles are in the directory /home/sysadmin/bkup_restore/

Invalid IP addressIf 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.4610:22:27 ERROR: System, 47.47.47.46, could not be pinged10:22:27 Remote Backup verification failed,

aborting backup processLogs are written

to/export/home/sysadmin/bkup_restore/mcp_backup...

For restore operations, if an invalid IP address is entered after the ufsrestorecommand is executed, an information message is displayed. Exampleoutput:ufsrestore rfsv [email protected]:/dev/rmt/Ocn 1Fri Feb 617:06:14 CST 200448.48.48.48: Connection timed out before Fri Feb 6 17:11:03CST 2004

Connection to remote tape server is lostIf a BCP 7200 loses connection to the tape drive during a backup, thesystem displays error messages on the screen.

Example output

As the mcp_backup script hangs, type Ctrl-C to abort. (To kill the processfrom another session type=> kill -9 <pid>.)



.


Tape drive failureIf something happens to the tape drive during a backup, an informationmessage appears. Example output:DUMP: write: I/O errorDUMP: write error 8320 blocks into volume 1DUMP: Do you want to restart?: ("yes" or "no")

Answer no to this prompt. The script terminates and another backup canstart. 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) dumpcommands=>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 BACKUPWILL FAIL19:29:15 Fix the associated problem, and perform anotherbackup19: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 tapesWhen restoring from multiple tapes, if you press Enter before inserting thenext tape into the tape drive, the restore process must be restarted.

To recover, continue to press Enter until the restore program reports aRead error.

The following message appears:Logs are written to/export/home/sysadmin/bkup_restore/mcp_recover.pl.log.2004_03_24.12:49:35

After the message appears, restart the restore procedure.

USB tape drive installation errorFollow this procedure to fix an error in the installation of a USB tape drive.

Procedure 37Fixing an error in the installation of a USB tape drive

Step Action

At the server,



.


1 If you receive an error while installing a USB tape drive, reboot theserver.

2 Log on as root.

3 Type the command shutdown -y -g0 -i6

4 Press Enter.

—End—



.




.

Nortel Multimedia Communication Server 5100

Border Control Point FundamentalsCopyright © 2007, Nortel NetworksAll Rights Reserved.

Publication: NN42020-108Document status: StandardDocument version: 01.04Document 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, configurations, technical data, andrecommendations in this document are believed to be accurate and reliable, but are presented without express or impliedwarranty. Users must take full responsibility for their applications of any products specified in this document. The information inthis 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.

http://www.avaya.com/documentfeedback

avaya bcp - nn42020-108_01.04_bcp

Documents

prevents unbounded

dataf illed

ne instance

rtp portal

rtp portal

ne instance

cluster remains

unforeseen