Troubleshooting

This section describes how to enable message tracing facilities as a tool for determining whether call control by the call agent is working.

To configure IPDC, perform the following tasks:

1. Switch node operation from IPDC to MGCP.

a. Issue the chprotocol 1command. The system automatically reboots.

b. Verify the change using the lsndinf command.

2. Set the IP addresses and ports for call control by a call agent via the MGX 8260 node management ports.

a. Set the local address and ports on Network 1 using the chmgcplocaladdr1 command.

b. If your system uses network redundancy, set the local address and ports for Network 2 using the chmgcplocaladdr2 command.

c. Set the primary media controller addresses and ports using the chpmgcpaddr command.

d. If your system includes a redundant media gateway controller (call agent or soft switch), set the secondary media controller addresses and ports using the chsmgcpaddr command.

e. Define the MGCP domain name using the chmgcpdname.

f. Check your configuration using the lsmgcpdef command.

3. Configure MGCP core parameters.

a. Specify the desired parameters using the chmgcpcore command.

b. Confirm the changes using the lsmgcp command.

4. Configure default call setup parameters.

a. Specify the default call setup parameters using the chmpc command.

b. Confirm the changes using the lsmpc command.

5. View MGCP voice parameters—use the lsmgcpvoice command.

6. View default call setup parameters—use the lsmpc command.

7. View MGCP protocol statistics—use the lsmgcpstat command.

---

Note   The MGCP protocol collects these statistics continuously after the SCC powers up or resets; you can't reset these counters. This display is a troubleshooting tool for use by experienced technicians who understand the protocol.

---

For example,

Debug information will not print on the screen until the command ttyredir 1 is entered. This command redirects console information to the terminal.

Note   Printout to the terminal can be inhibited by entering ttyredir 0. However, once trace debugging is turned on and even though the trace output is not directed to the terminal, system performance will still be drastically slowed down.

You should also change the idle time prior to session disconnect to an interval longer than is necessary to run the trace. Use the command chidletm <minutes> to increase the time-out interval.

Caution   System security maybe jeopardized if the idle time-out value is changed to a very large number. If the telnet session is left unattended for a long interval unauthorized personnel may gain access to the system. The time-out value should be restored to its original value immediately following trace debugging activities.

Turn off IPDC trace debugging by entering the command mgcpPrtOff.

Another debug trace command—prtOn <number>—traces the messaging associated with a single software element and prints the results. For example:

prtOn 30—MGCP protocol call control (MPC) full trace debugging

prtOn 31—MGCP protocol call control (MPC) Errors

prtOn 32—MGCP protocol call control (MPC) Control Interface

ISDN Layer 2 (LAPD) runs on service cards (NSCs or BSCs).

Note   Backhaul protocol is only supported if the call control protocol type is MGCP. Backhauling is not supported for call control via IPDC.

An MGX 8260 can be configured to have multiple sessions sets between the MGX 8260 and an MGC.

The call agent must request notification of announcement events from the media gateway or Notify messages are not sent.

• lssession—shows information about a particular session
  
  
• lssessions—shows information about all current sessions
  
  
• lsgroup—shows information about a particular session group
  
  
• lsgroups—shows information about all current session groups
  
  
• lsset—shows information about a particular session set
  
  
• lssets—shows information about all current session sets
  
  

To display information about all ISDN D channels use the lsdchans command

You can display performance statistics related to ISDN backhaul operation via the following commands:

• Circuit cards installed, removed, or replaced
  
  
• Media gateway controller serviced
  
  
• Ethernet LAN devices and/or cables installed, removed and replaced
  
  
• Fan module removed and replaced
  
  
• Power supply removed or replaced
  
  
• Cable changes
  
  
• Configuration changes made to MGX 8260 media gateway, media gateway controller (call agent, soft switch), adjunct routers/switches, and/or network management system
  
  
• Software upgrades/downgrades to MGX 8260 media gateway and/or media gateway controller
  
  
• Corrective maintenance procedures performed on MGX 8260 node
  
  
• Intermittent problems
  
  
• Related comments
  
  

The complete scope of the database configuration process is described in the Cisco MGX 8260 Configuration Guide.

The database configuration process has the potential to be mishandled when:

If operational problems are encountered shortly after one of the above functions has been performed, the likely cause is erroneous, mismatched or missing database entries. These problems will usually manifest themselves as misrouted or incomplete calls.

Getting the digital spans to the installation site may require a great deal of configuration effort external to the MGX 8260. A number of aggregation and routing devices may be in the chain leading to delivery of services. For SS7 links the complexity of the configuration requirements escalates exponentially.

Physical wiring of the service must match the requirements of the MGX 8260 service circuit cards. Miswired connections can damage components in the media gateway. Damage to the digital facilities -lightning, cut cables, loss of power—will also cause operational problems in the MGX 8260.

Signaling issues—DTMF vs. MF receivers, frame format, signaling protocols—must be accommodated through MGX 8260 line and port configurations.

Anomalies can also be caused by the interaction of the MGX 8260 node with call agent applications. The Release Notes accompanying the currently running version of the call agent should identify:

• Interoperability issues
  
  
• Known anomalies
  
  
• Reconfiguration requirements
  
  
• Workarounds.
  
  

If the problem has not been previously identified, careful notice should be taken of the exact circumstances that revealed the problem. The problem should be immediately reported to the system integrator and/or Cisco TAC for analysis and resolution.

The weakest components in the system are those which require continuous mechanical activity—cooling fans. A lack of air flow resulting in the sudden build-up of heat can cause other components to operate erratically or fail completely. Checking fan operation on all system components is a relatively simple precaution that can greatly enhance overall node availability.

Up to 20 general user profiles can be defined for an MGX 8260 node. Each profile specifies the user name, default password and access level. The root user has unrestricted access to all node features and functions.

Note   The maximum number of simultaneous user sessions can be restricted by a root user issuing the ussescli command (refer to Appendix A).

Following login, users can type help and press Enter to display the CLI commands available to them. Similar restrictions will be encountered when selecting WebViewer menu options.

Note   SuperUser and root privileges are not identical. The root user can configure a number of database entities directly from the command line. The additional CLI, VxWorks and Engineering debug commands available to a root user are listed in Table A-2, Table B-1 and Table B-2 respectively.

Communication via the serial ports requires the following settings on the terminal:

• 9600 bps
  
  
• 8 data bits
  
  
• 1 stop bit
  
  
• No parity
  
  
• No flow control
  
  

The connection to the DB9S female Console port on the SCC back card requires a null modem cable. The DB9S modem port needs a straight-through cable. Refer to the Cisco MGX 8260 Hardware Installation Guide for detailed pinout requirements.

With the terminal connected to the Console or Auxiliary ports, launch a session. Strike the Enter key to obtain a login prompt.

Entering a valid login and password will display the Command Line Interface (CLI) prompt.

The prompt shows the node name (POPB), physical slot number of the SCC (9) and its current operating mode (ACTIVE). Although standby and active are the expected operating modes, the SCC can be in other modes. For example, upon boot-up, the SCC can be in PLFM-ACTIVE, MSTR-SYNC, SLAVE-SYNC or one of several other modes. While in these modes, the SCC will allow a user to logon. However, the SCC will not respond to any CLI commands.

Initiating a telnet session by specifying only the IP address of the node will always establish a session with the active SCC module.

For example, the command:

>telnet 10.100.80.20

establishes a terminal session with the active SCC.

You can telnet to another circuit card in the MGX 8260 node by ending the IP address with the suffix 80xx, where xx is the target card's physical slot number.

For example, the command:

>telnet 10.100.80.20 8001

establishes a telnet session to the service circuit card in slot 1 of the target node.

Similarly, the command:

>telnet 10.100.80.20 8010

establishes a telnet session to the SCC in slot 10, regardless of whether it is in active or standby mode.

Note   Attempting to telnet to a non-existent card will result in a telnet time-out.

After establishing a telnet session, the MGX 8260 responds with the login prompt. Entering a valid login and password will place the user at the familiar CLI prompt.

Entering a valid login and password will display the Command Line Interface (CLI) prompt.

If the login prompt does not appear, check the following:

1. Verify that the command and the IP address were properly typed.

2. Check all physical connections between the workstation , MGX 8260 and LAN.

3. Verify (via a console session) that the node's IP address is configured as expected.

4. Verify network connectivity by initiating a "ping" from the workstation to the node.

Any command or configuration possible via the Console port can be achieved via a telnet session with the sole exception of initially configuring the node's IP address.

Note   It is possible to alter the IP address used by the active telnet session, but this will result in the active telnet session being lost and the user having to reestablish a telnet session to the new IP address.

Note   There may be a slight delay while you are waiting for the WebViewer HTML files to be downloaded from the MGX 8260 server. You may also be prompted by the browser to certify acceptance of the running of Java scripts.

If the WebViewer GUI screen does not appear after entering the IP address on the browser's address bar, check the following:

Caution   Configuring the in-band management capability requires resetting the MGX 8260 node. Resetting the node is service affecting and should be done only during a prescribed maintenance window if the MGX 8260 is already carrying live traffic.

The In-Band IP address may be configured using the chibip command.

For example

Use the lsmgips command to verify that the in-band IP address has been properly set:

The MGX 8260's default gateway must be set to match the Fast Ethernet's primary gateway using the chgw command.

For example,

CMGM supports four major system management functional areas—fault monitoring, node configuration, performance monitoring, and security. CMGM also conforms to the Telecommunications Management Network (TMN) model, operating as an EMS at the element management layer.

CMGM supports the following features:

• Auto-discovery and configuration of MGX 8260 nodes
  
  
• Software image and configuration download to the MGX 8260
  
  
• Web-based device management
  
  
• Performance monitoring on DS1, DS3, and SONET facilities
  
  
• Real-time and proactive network surveillance
  
  
• Threshold-based alarms
  
  
• E-mail/page alert for alarms
  
  
• Line diagnostic tests
  
  
• Comprehensive fault management for increased reliability
  
  

CMGM communicates with the MGX 8260 nodes using SNMPv1 and TFTP protocols.

For additional information, refer to the following Cisco publications:

• Backing up database files
  
  
• Verifying general operating parameters
  
  
• Visually inspecting cables and connectors
  
  

---

Note   Blank panels should be installed over all slots not containing front or back cards. The panels must remain in place during system operation for NEBS EMI compliance and adequate air flow.

---

Note   The backup process will briefly require CPU usage that may affect a node carrying heavy traffic.

For example,

Security Key

For example, from within the IMAGE subdirectory issue the following command:

Verify that the file has been copied by popping up to the root directory and issuing the list (ll) command.

File Transfer

Using the tftp command or any tftp software package running on a server, PC or workstation, transfer the backup file by initiating a tftp transfer to the MGX 8260 management IP address. Set for binary mode file transfer. Use the "get" command and the security key to obtain the desired database configuration filename.

Note   The security key is appended to the end of the filename preceded by a period; see the example below.

An example of a typical tftp transfer to a UNIX workstation follows:

Verify the currently active image on the MGX 8260 node by entering the CLI command version.

For example,

The software version has been highlighted in bold type. The matching file for this version is scc_r01.02.03.cfg.

Note   The security key must match the 6-digit key used when originally uploading the file.

Note   If the file has been renamed on the server, PC or workstation it must now be placed on the SCC flash disk using its original filename. Most tftp applications will readily allow a name change between the object and copied files.

Using the tftp command or any tftp software package running on a server, PC or workstation, transfer the backup file by initiating a tftp transfer to the MGX 8260 management IP address. Set for binary mode file transfer. Use the "put" command and the security key to obtain the desired database configuration filename.

Note   The security key is appended to the end of the filename precede by a period; see the example below.

If using a UNIX workstation the command sequence would be:

The MGX 8260 is equipped with multiple sensors which monitor these parameters. An administrator should periodically issue the CLI command lsemms to display the current operating state of the MGX 8260. A sample display appears below:

For additional information on using and interpreting the lsemms command, refer to:

DC Feeds

Ground

VoIP calls route over Fast Ethernet lines. VoATM calls route over SONET (OC-3) lines.

The COT tones—2010 Hz (co1) and 1780 Hz (co2)—can be set using the command chipdccot. Different COT tones may be used for receive and transmit operation; The default setting is 2010Hz (co1) for both receive and transmit operation. The user can display the configured COT tone(s) via the command lsipdccot.

Supported test line types include:

• Type 100—detects presence or absence of milliwatt tone
  
  
• Type 102—applies 1004Hz tone towards the originating office
  
  
• Type 108—provides far end loop termination for testing echo suppression
  
  

DS1 and DS3 Lines

Three types of loop back configurations are supported on DS1 and DS3 lines.

• No loop—default
  
  
• Payload loop—received signal is looped back for retransmission after it has passed through the local framing function.
  
  
• Line loop—signal is looped back over physical line without passing through the framing function.
  
  

SONET Lines

• No loop—default
  
  
• Line loop—signal is looped back over physical line without passing through the framing function.
  
  
• Serial loop
  
  
• Parallel loop
  
  

WebViewer

Note   WebViewer will not accept the root login name and password. You should login as a Level 1user (SuperUser) with full access privileges when initiating loopbacks.

CLI Commands

• ds1lncfgcli
  
  
• ds3lncfgcli
  
  
• sonetcfgcli
  
  

• Status LEDs
  
  
• Alarms
  
  
• Event Log
  
  
• Trap Log
  
  

• CLI commands
  
  
• Email alerts
  
  
• WebViewer
  
  
• SNMP trap messages
  
  
• Front panel indicators
  
  
• Relay contact closures
  
  

Details for the following categories of alarms can be viewed via CLI commands or the WebViewer:

• Shelf
  
  
• Card
  
  
• DS1
  
  
• E1
  
  
• DS3
  
  
• Fast Ethernet
  
  
• SONET OC-3
  
  
• Environment
  
  

---

Note   Many alarm thresholds can be adjusted via the CLI or WebViewer. An alarm is automatically cleared after the condition which generated it has been remedied.

---

The lsalms command displays the status of all shelf and card alarms in the MGX 8260 node. A sample printout appears below.

The system displays a summary of the trunk status, including the Operational Status for each line. Use the lsethln <slot.line> command to display specific alarm information for and an individual Fast Ethernet line. A sample of the information output for the FE line 1 on the SCC in slot 9 appears below.

To view alarms for SONET lines, use the lssonetstat command.

The trap log can be displayed from the WebViewer by issuing the CLI command lstraps. A sample of the output from the lstraps command appears below.

• Card self tests
  
  
• Line tests
  
  
• Display MRPC transactions
  
  
• On-line diagnostics
  
  

All the circuit cards use the same boot sequence. The card initially boots up using the boot flash files stored on its flash PROMs. While the card is booting up, its Card LED flashes red. Following boot up the card attempts to download the image software from the active SCC; the Card LED flashes yellow.

After downloading the image software the Card LED again flashes red. It then executes the software (the Card LED flashes yellow) and enters its operating state. If the card test is successfully completed and the card becomes active, its Card LED illuminates green. If the test is successful and the card is in standby mode, its card LED illuminates yellow. If the card test fails, the card LED illuminates red.

Note   Several attempts (up to five) may be required for the NSCs or BSCs to successfully download the image software. If so, the card will reinitiate that segment of the boot process. The Card LED will again flash red, then yellow, and finally solid green, yellow or red.

To display the contents of the diagnostic table for all circuit cards, issue the CLI command lsonds. A sample output of the lsonds command appears below.

To display detailed diagnostic information for a specified card, issue the CLI command lsond <slot>. A sample output appears below.

Fault isolation involves identifying a problem, analyzing its cause, and applying the appropriate solution. The MGX 8260 incorporate extensive error messaging and logging facilities which help in the identification process. Problems tend to have multiple causes which must be identified, individually analyzed, tested, and confirmed. Repair attempts that simply replace components on a hit-or-miss basis usually mask rather than resolve actual causes of system malfunctions.

The media gateway controller (call agent or soft switch) can trigger events in the MGX 8260 that can have the effect of placing portions of the system out of service. Replacing cards and performing other corrective maintenance procedures will not cure a fault originating at the call agent.

MGX 8260 operation depends on data entered into its configuration database by the administrator. The MGX 8260 node is coupled to external carrier facilities that should be carefully mapped and updated as changes are made to the MGX 8260 configuration.

The technical documentation set supplied with the MGX 8260 contains information about, and organizational tools for, installing and maintaining an MGX 8260 node.

• Carrier services
  
  
• Media gateway controller (call agent or soft switch)
  
  
• Node management (direct and in-band Ethernet)
  
  
• IP network devices and configuration
  
  
• Power and ground irregularities
  
  

When individual carrier lines fail, system performance degrades because calls are blocked from obtaining service or completing a connection to the intended destination. Statistical reports log the loss of service. Signaling requirements (SS7, DTMF, MF) vary widely from carrier to carrier. The MGX 8260 must be configured to correctly process incoming and outgoing signals.

When a block of carrier circuits fails, the more likely cause of the problem is the failure of a MGX 8260 circuit card. A digital line can be lost at its demarcation point, the service provider's digital switch, or at its interface point with the MGX 8260.

• Failure to complete calls through the system due to:
  
  
• Incomplete or erroneous database entries that affect call routing (routes, SS7 configuration, carrier configuration, dialing configuration)
  
  
• Mismatched database information (signaling requirements, codec transcoding, etc.)
  
  
• Lack of or undefined processing resources (digital lines and/or channels, announcements, multiservice modules)
  
  
• Throttling caused by improper overall system configuration, including session management over Ethernet ports (direct or in-band)
  
  
• Alarm conditions triggered by the call processing application
  
  
• Interprocess communication failure within solution network
  
  
• Failure of one or more processors supporting the call agent application(s)
  
  

The call agent generates its own error messages. Such alarms are usually the result of a failure in call processing or interprocess communication. A detailed error message should indicate why the alarm was triggered so that a service technician can quickly isolate and remedy the cause.

The management links can become saturated with messages as call processing escalates. Although the MGX 8260 supports up to 21 simultaneous user logins, the actual number of logins will be limited by the total number of calls being actively processed.

Note   To assure reliable communications regardless of the volume of messaging, configure the Ethernet management and Fast Ethernet ports for half-duplex operation. Other network devices interfacing with the MGX 8260 media gateway must be also configured for half-duplex operation.

Problems associated with node management interfaces can manifest themselves as follows:

• Inability to login into the node via telnet or WebViewer session
  
  
• Halt in call processing due to messaging timeouts between the call agent and MGX 8260 node
  
  
• Messaging alarms at an element management system or network management system due to messaging timeouts or loss of IP communications
  
  
• Degradation in QOS through routers and switches due to excessive queuing of IP packets
  
  
• Dramatic decrease in the number of VoIP calls that can be processed over FE ports
  
  

Caution   Users must avoid initiating simultaneous and conflicting changes to the MGX 8260 configuration database. This can be accomplished by restricting the number of users with high level access privileges.

IP network problems may result in the following:

The IP network within which the MGX 8260 will operate must be properly engineered and configured to support the anticipated levels of IP traffic.

Note   As of MGX 8260 software release 1.4, Cisco no longer supports voice over IP (VoIP) functionality for the MGX 8260.

Caution   The MGX 8260 system must receive input power from an uninterruptible source, capable of sustaining system operation during prolonged power outages.

Intermittent power surges and sags, as well as induced noise caused by a faulty ground, can produce the following problems:

• Database errors
  
  
• CPU and memory
  
  
• Mass storage
  
  
• Interface and service circuit hardware problems
  
  
• Software/firmware incompatibility
  
  

Problems with the media gateway database can result in the following:

• Failure to complete calls processed through the system
  
  
• Frequent halts to call processing
  
  
• Poor grade of service performance
  
  
• Rejection of multiple messages sent by the call agent or element/network management systems
  
  
• Inability to connect or reconnect to the MGX 8260 node by users, the call agent or element/network management systems
  
  
• Signaling problems over carrier facilities
  
  

Tracing database problems requires a very detailed examination of database entries across all of the individual tables associated with a potential problem.

• Continuous node reinitialization
  
  
• Failure to completely initialize the system
  
  
• Frequent file related errors
  
  
• Inability to update, backup or restore the configuration database
  
  
• Failure to recognize and/or complete call attempts
  
  
• MRPC messaging failures between redundant card types
  
  
• Communications problems via Ethernet management ports, Fast Ethernet or SONET OC-3 lines
  
  
• Call control (IPDC or MGCP) session failures
  
  
• Message parsing errors
  
  

• File transfer errors between system memory and the database
  
  
• Inability to open, close, read from, or write to a file
  
  
• Failure to download data from disk to downloadable cards
  
  
• Denial of access to error logs
  
  
• Inability to log in
  
  

• Software/firmware incompatibility
  
  
• Incorrect interface configuration
  
  
• Environment (operating temperature, voltage levels and static electricity)
  
  
• Transient power surges
  
  
• False signaling from external sources (lightning, transient or recurring overvoltage or shorts)
  
  
• Faulty midplane connections
  
  
• Discrete component failures
  
  

If you experience system problems after loading new software or when replacing a circuit card, check for firmware compatibility. Always refer to the configuration information contained in the Release Notes. Download the correct firmware from Cisco Connection Online (CCO).

Caution   Occasionally, the SCC's configuration database may be corrupted as a result of a software image upgrade/downgrade. To clear this, issue the SccClearCfg command followed by a resetcd <slot> command. Initiating this command sequence will delete the database configuration. The database is automatically rebuilt from the active SCC (redundant configuration) or can be manually restored using the dbrstr <filename>. (Refer to Appendix A and Appendix B for additional information.)

TCG performs the following tasks:

• Handles asynchronous activity from MSM/DSPs
  
  
• Sends announcements to an MSM/DSP
  
  
• Performs heartbeat polling of MSM/DSPs for possible failure
  
  

All DSP channels in an MGX 8260 node are placed in a single pool that is managed by the resource manager (RMG) module. Channel capacity for an individual MSM on an NSC is as follows:

• For T1, 192 channels for G.711 coding (112 channels for G.726 or G.729)
  
  
• For E1, 240 channels for G.711 coding (112 channels for G.726 or G.729)
  
  

---

Note   Each NSC supports two MSMs. One voice path may require one or two DSP channels.

---

• Loss of QoS over IP network (excessive jitter, transcoding failures, detectable echo)
  
  
• Call timeouts waiting for announcements
  
  
• Unavailable test facilities (COT, test lines)
  
  

Note   The MGX 8260 will not resume operation until all components affected by the power disruption have successfully reinitialized.

If the power disruption is transient and followed by an immediate restoration of power, a high magnitude power surge may damage system components. If the system fails to successfully initialize, begin searching for indications of damage to the MGX 8260 circuit cards.

• Inspect cabling between terminating devices. Verify that cables have been correctly connected to their target ports (miswiring error).
  
  
• Verify port-to-port heartbeat indication on terminating devices.
  
  
• Verify port configuration.
  
  
• Use ping command to confirm port access.
  
  
• Track network messaging with CLI commands and "snooper" program.
  
  
• Review network setup to confirm accessibility and protocol handling among all devices.
  
  
• Review MGX 8260 Release Notes to confirm support for desired protocols.
  
  
• Replace faulty components.
  
  

• NSCs can be added in slots 1- 8 and slots 11-16.
  
  
• BSCs can be added in slots 11—16.
  
  
• DMCs can only be added in slots 7 and 8.
  
  

Service circuit cards can be added to an operational MGX 8260 node currently processing calls. Following physical installation, the card(s) must be configured for redundancy and line-level signaling. The added cards can then be recognized by the call agent or soft switch as being an available resource for handling calls.

Step 9   Use a narrow bladed screwdriver to tighten the captive screws at the top and bottom of the front panel.

Step 10   If the card requires a back card, identify the slot into which it will be installed.

Step 11   Remove the blank plate covering the back card slot.

Step 12   Remove the back card from its antistatic envelope.

Step 13   Align the card within the top and bottom card rails in the chassis.

Step 14   Flip up the ejectors on the top and bottom of the card's rear panel.

Step 15   Push the card inwards until the card just touches the connectors on the midplane.

Step 16   With the base of the ejectors hooked over the chassis rails, press firmly downward on the ejectors until the card is fully seated in the midplane connectors.

Step 17   Press firmly on the card's rear panel until it is flush with the chassis card rails.

Step 18   Use a narrow bladed screwdriver to tighten the captive screws at the top and bottom of the rear panel.

Step 19   Label and connect interface cables to the back card. Refer to the Cisco MGX 8260 Hardware Installation Guide.

---

Note   Use Y-cables to connect interface cables across BSCs and DMCs in mated pairs. If the new card will be redundantly paired with an existing card, stop call routing through the existing card before disconnecting the interface cables.

---

Step 20   Use the CLI command: lscd <slot> to verify that the new card has successfully booted and has come up in active mode.

Step 21   If the card is to be configured for redundant operation, use addreds to establish the redundant pairings. If the card will not be configured for redundant operation, proceed to line configuration.

• Hardware configuration of the two BSCs must be identical.
  
  
• Firmware version of the two BSCs must be identical.
  
  
• New BSC must not have any lines configured.
  
  
• Y-cables must be installed to span the DS3 lines across the same ports on both BSCs.
  
  

To configure BSC redundancy, follow these steps:

Step 1   Log into the active SCC.

Step 2   Add a redundancy pair using the addreds command.

Step 3   Verify that pairing has been created by issuing the lsreds command.

Step 1   Verify that the secondary NSC has a redundant back card installed and is in the standby state. Enter the lscd command, specifying the card number, to verify the hardware and status:

Step 2   Verify that each primary, active NSC is in the back card mode and is in the active state. List the operational status of all cards using the lscds command.

Step 3   Add a redundancy pair using the addreds command, specifying the primary and secondary slots.

The primary slot is active during normal operation. The secondary slot is in standby mode during normal operation and protects the primary slot in the event of a primary failure.

The following example creates a redundancy pair with slot 1 as primary and slot 3 as secondary:

Step 4   Repeat the previous step to assign additional primary slots to the designated secondary slot. Each MGX 8260 chassis can have only one secondary NSC slot.

Note   The system stops adding lines on the first failure, even if later additions are valid.

Verify the configuration for the new lines using the lsds1ln command, specifying the logical number of the slot in the MGX 8260 chassis and the number of the DS1/E1 line, delimited by a period (slot.line). The display identifies the associated DS3 line, if appropriate.

Note   The logical slot number for all cards can be displayed by issuing the CLI command lslgcds.

A single DS3 can map to multiple NSCs or multiple DS3s can map to a single NSC. Map definitions can be organized or arbitrary, but often occur in contiguous groups because you can define a range of mappings with a single command. The MGX 8260 Media Gateway stores map definitions in a map table.

You can initialize or alter the map table from the WebViewer or from the CLI.

You can add map entries individually or within a range. When adding individual map entries, the following restrictions apply:

• Map requests cannot duplicate existing entries.
  
  
• Map requests cannot specify non-existent source or destination lines.
  
  

You simplify the process of mapping DS3 to DS1 lines by mapping a range of DS1s rather than individual lines. A map range is added in a sequential and contiguous manner, and can cross either source or destination boundaries.

The entire range of source and destination lines must be contiguous. The system stops mapping lines if it encounters a source or destination that is already assigned, leaving map pairs before the contiguous break assigned and the rest unassigned.

Voice ports are not required for calls terminating on BSCs.

The minimal system consists of a primary MGC, the MGX 8260 node, and an IP network. You can add a secondary network and/or MGC for reliable operation.

The backhaul sessions and groups include the following components in ascending hierarchical order:

When adding sessions, you create a structure that supports reliable operation. The goal for a fully-redundant system is to provide multiple management sessions to multiple MGCs via multiple physical networks.

With full redundancy, you configure the following: