(Page 1 of 1 in this chapter) Version

Chapter 6

Setting Up a Redundant System

6.1 Board Installation and Cabling
6.2 Configuration
6.2.1 HMI Configuration
6.2.2 ss7load Script Configuration
6.2.3 MTP Configuration
6.2.4 ISUP, TCAP, and SCCP Configuration
6.3 Running the HMI service
6.3.1 Windows NT
6.3.2 UNIX
6.4 Bringing up a Redundant System
6.4.1 Starting txalarm
6.4.2 Loading and Setting Board States
6.4.3 Starting Data Traffic

6.1 Board Installation and Cabling

There are no special considerations for installing TX boards for redundant configurations. See the TX installation manual for your particular board model for installation instructions.

After installation, the redundant board-pair must be connected with an Ethernet crossover cable (provided by NMS). The location of the Ethernet port depends on the particular board model, as shown in the following diagrams:

Figure 15. TX 3000 or TX 3220 Redundancy Cabling Model (Dual Node)





Figure 16.	 TX 3220C Redundancy Cabling Model (Dual Node)




Simply cabling the two boards together determines which boards operate together as mated pairs. No configuration of mate addresses or board numbers is necessary.






6.2	 Configuration





Configuring a system for redundant operation requires modifications to four different components: HMI, the ss7load script, MTP, and ISUP.






6.2.1	 HMI Configuration





The HMI service requires a text configuration file named hmi.cfg to identify the boards to be monitored and other run time parameters. The HMI configuration file is found in the following locations. 



Windows NT:   \tektx\config\hmi.cfg



UNIX:   /etc/txn/hmi.cfg






The sample HMI configuration file created by the software installation utility for Windows NT is shown in the following example. The UNIX file is identical except for the format of the path name for the download files.


   BOARD_NUMBER1     1
   SS7LOAD_FILE1     c:\\tektx\\ss7load.bat
   BOARD_NUMBER2     2
   SS7LOAD_FILE2     c:\\tektx\\ss7load2.bat
   END




HMI configuration parameters are described in the following table. Parameters may be specified in any order. The BOARD_NUMBERn and SS7LOAD_FILEn can be repeated for up to eight boards.  







Parameter Name







Range







Default







Description







 BOARD_NUMBER1



 1 - 8



 None



 Board number to manage




 SS7LOAD_FILE1



 N/A



 None



 File and path name of the batch file used to download the board - make sure file is board specific




 BOARD_NUMBER2



 1 - 8



 None



 Board number to manage




 SS7LOAD_FILE2



 N/A



 None



 File and path name of the batch file used to download the board - make sure file is board specific















Note:  The HMI cannot pass any arguments (i.e., the board number) to the ss7load script; therefore, if multiple boards are being configured on a single node, each board must have its own ss7load script with an explicit board number. The default ss7load script is a generic script which accepts the board number as an argument and defaults to board number 1 when the board number is not specified.

 Configuring Port Numbers for the HM API



The HM API uses one UDP port number for its APIs - the same for unsolicited events and for conversational requests. By default, port number 1801 is used for this purpose. If other applications are using this port number on the target system, it may be changed by adding the appropriate entries to the TCP/IP Services directory (on Windows NT this is in the %SystemRoot%\system32\drivers\etc directory). Both the HMI service and the HM API libraries check for the appropriate service name/port assignments with the standard sockets getservbyname primitive before using the default values.



The service name is hm_api. For example, the following entry in the services file would change the UDP ports used to 1750.


   hm_api     1750/udp     # Tx Series HM API service




This entry is read only at startup time; so, in order to change these values, the HMI service and all applications using the HM API must be stopped and restarted.







6.2.2	 ss7load Script Configuration 





The ss7load script contains commands necessary to download a board with the proper protocol tasks and configuration files. The ss7load script is found in the following locations: 



Windows NT   \tektx\ss7load.bat



UNIX   /usr/bin/SS7load






For redundant configurations, the ss7load script must download two additional tasks: the arp.lot task and the txmon.lot task. A fragment of a sample ss7load script is shown in the following examples. The new entries required are shown in boldface type.


 Windows NT


. . .

rem
rem Download the TDM configuration
rem
%TXUTIL%\cplot -c %BRD% -f %TXCONFIG%\TDMcp%BRD%.bin -g tdm
rem
rem Download the executable tasks
rem 
%TXUTIL%\cplot -c %BRD% -f %TXCP%\arp.lot -n arp -p 10 -a
%TXUTIL%\cplot -c %BRD% -f %TXCP%\txmon.lot -n txmon -p 5 -a
%TXUTIL%\cplot -c %BRD% -f %TXCP%\inf.lot -n inf -p 16 -a
%TXUTIL%\cplot -c %BRD% -f %TXCP%\mvip.lot -n mvip -p 4 -a
%TXUTIL%\cplot -c %BRD% -f %TXCP%\t1e1mgr.lot -n t1e1mgr -p 15 -a
%TXUTIL%\cplot -c %BRD% -f %TXCP%\mtp.lot -n mtp -p 10 -a -s 12000
%TXUTIL%\cplot -c %BRD% -f %TXCP%\isup.lot -n isup -p 12 -a -s 40960
%TXUTIL%\cplot -c %BRD% -f %TXCP%\sccp.lot -n sccp -p 11 -a
%TXUTIL%\cplot -c %BRD% -f %TXCP%\tcap.lot -n tcap -p 13 -a
%TXUTIL%\cplot -c %BRD% -f %TXCP%\tup.lot -n tup -p 12 -a -s 40960
rem
rem Enable the download of the ISUP database required for your configuration.
REM
%TXUTIL%\cplot -c %BRD% -f %TXCP%\ituwhite.lot -n ituwhite -p 5 -a
rem %TXUTIL%\cplot -c %BRD% -f %TXCP%\itublue.lot -n itublue -p 5 -a
rem %TXUTIL%\cplot -c %BRD% -f %TXCP%\q767.lot -n q767 -p 5 -a
rem %TXUTIL%\cplot -c %BRD% -f %TXCP%\ansi88.lot -n ansi88 -p 5 -a
rem %TXUTIL%\cplot -c %BRD% -f %TXCP%\ansi92.lot -n ansi92 -p 5 -a
rem %TXUTIL%\cplot -c %BRD% -f %TXCP%\ansi95.lot -n ansi95 -p 5 -a
REM
REM Configure SS7 MTP2, MTP3, ISUP
REM
%TXUTIL%\mtp2cfg -b %BRD% -f %TXCONFIG%\MTP3cp%BRD%.cfg
%TXUTIL%\mtp3cfg -b %BRD% -f %TXCONFIG%\MTP3cp%BRD%.cfg
%TXUTIL%\isupcfg -b %BRD% -f %TXCONFIG%\ISUPcp%BRD%.cfg
%TXUTIL%\sccpcfg -b %BRD% -f %TXCONFIG%\SCCPcp%BRD%.cfg
%TXUTIL%\tcapcfg -b %BRD% -f %TXCONFIG%\TCAPcp%BRD%.cfg
%TXUTIL%\tupcfg -b %BRD% -f %TXCONFIG%\TUPcp%BRD%.cfg

. . .

 UNIX

. . . 

# load TDM configuration if needed
cplot -c $1 -f $CONFIGBASE/TDMcp$1.bin -g tdm

# load executable tasks
cplot -c $1 -f $TX2BASE/arp.lot -n arp -p 10 -a
cplot -c $1 -f $TX2BASE/txmon.lot -n txmon -p 5 -a
cplot -c $1 -f $TX2BASE/inf.lot -n inf -p 16 -a
cplot -c $1 -f $TX2BASE/mvip.lot -n mvip -p 4 -a
cplot -c $1 -f $TX2BASE/t1e1mgr.lot -n t1e1mgr -p 15 -a
cplot -c $1 -f $TX2BASE/mtp.lot -n mtp -p 10 -a -s 12000 
cplot -c $1 -f $TX2BASE/sccp.lot -n sccp -p 11 -a
cplot -c $1 -f $TX2BASE/isup.lot -n isup -p 12 -a -s 40960
cplot -c $1 -f $TX2BASE/tcap.lot -n tcap -p 13 -a
cplot -c $1 -f $TX2BASE/tup.lot -n tup -p 12 -a -s 40960

# Download the ISUP database required for your configuration.
cplot -c $1 -f $TX2BASE/ituwhite.lot -n ituwhite -p 5 -a
#cplot -c $1 -f $TX2BASE/itublue.lot -n itublue -p 5 -a
#cplot -c $1 -f $TX2BASE/q767.lot   -n q767  -p 5 -a
#cplot -c $1 -f $TX2BASE/ansi88.lot -n ansi88  -p 5 -a
#cplot -c $1 -f $TX2BASE/ansi92.lot -n ansi92  -p 5 -a
#cplot -c $1 -f $TX2BASE/ansi95.lot -n ansi95  -p 5 -a

. . . 

# Load SS7 configuration files
mtp2cfg -b $1 -f $CONFIGBASE/MTP3cp$1.cfg
mtp3cfg -b $1 -f $CONFIGBASE/MTP3cp$1.cfg
isupcfg -b $1 -f $CONFIGBASE/ISUPcp$1.cfg
sccpcfg -b %BRD% -f %TXCONFIG%/SCCPcp%BRD%.cfg
tcapcfg -b %BRD% -f %TXCONFIG%/TCAPcp%BRD%.cfg
tupcfg -b %BRD% -f %TXCONFIG%/TUPcp%BRD%.cfg

. . .



Note:  For standalone configurations, where the health management system is employed for board monitoring only, the arp.lot task is not required and can be removed from the ss7load script. The txmon.lot file is still required for standalone configurations.


The ss7load script is called by the HMI process, as shown in the HMI configuration file (see Section 6.2.1). In the sample HMI configuration file, there are two versions of the ss7load script file, ss7load.bat, and ss7load2.bat. The first script loads board 1 and the second script loads board 2. It is important that both ss7load scripts are modified as shown earlier in this section. If the ss7load script file names are changed, be sure that their references in the HMI configuration file are changed as well.






6.2.3	 MTP Configuration





A typical redundant configuration includes signaling links terminated on both boards in a mated pair. The MTP configuration for each board must include both links terminated on its own board and the links terminated on the mate board. The following example illustrates a simple MTP configuration file for each board of a mated pair with one link terminated on each board:


# Board 1 MTP Configuration          # Board 2 MTP Configuration
#-----------------------             #-----------------------
#Overall MTP3 Parameters             #Overall MTP3 Parameters
#-----------------------             #-----------------------

NODE_TYPE SP                         NODE_TYPE SP
. . .                                . . .
   <identical to board 2>               <identical to board 1>
. . .                                . . .
#------------------------            #------------------------
#Link 0                              #Link 0
#------------------------            #------------------------
LINK  0                              LINK  0
PORT  T1 # Board 1, TDM 1            PORT  R # Remote (board 1)
LINK_SET 1                           LINK_SET 1
ADJACENT_DPC 2.2.2 # Adjacent STP    ADJACENT_DPC 2.2.2 # Adjacent STP
LINK_SLC 0                           LINK_SLC 0
TIMER_T31  1                         TIMER_T31  1
LSSU_LEN 2                           LSSU_LEN 2         # ignored: remote
END                                  END
#------------------------            #------------------------
#Link 1                              #Link 1
#------------------------            #------------------------
LINK  1                              LINK  1
PORT  R # Remote (board 2)           PORT  T1 # Board 2, TDM 1
LINK_SET 1                           LINK_SET 1
ADJACENT_DPC 2.2.2 # Adjacent STP    ADJACENT_DPC 2.2.2 # Adjacent STP
LINK_SLC 1                           LINK_SLC 1
LSSU_LEN 2         # ignored: remote LSSU_LEN 2 
END                                  END
#---------------------------------   #---------------------------------
#User Parameters (NSAP definition)   #User Parameters (NSAP definition)
#---------------------------------   #---------------------------------
. . .                                . . .
   <identical to board 2>               <identical to board 1>
. . .                                . . .




The locally terminated links are fully configured with physical port identifiers and all layer 2 and layer 3 parameters. The links terminated on the mate board contain no physical port identifiers or other layer 2 parameters; instead, they are specified as Remote (R).


Note:  Each relative link number (link 0, for example) refers to the same link - on board one, it is fully configured since it is terminated locally. On board two, only the layer 3 parameters are specified, since the link is not terminated on board two (layer 2 parameters can be specified in this case, but they have no affect).


Other sections of the MTP configuration, such as link sets, routes, and service access points are typically identical on both boards in the mated pair. 



For more information on the MTP configuration, see the SS7 Installation and Configuration Manual.






6.2.4	 ISUP, TCAP, and SCCP Configuration





There are no specific ISUP, TCAP, or SCCP configuration requirements for redundant board configurations. Both boards in a mated pair will typically have identical configurations.



For more information on the ISUP, TCAP, and SCCP configurations, see the SS7 Installation and Configuration Manual.






6.3	 Running the HMI service





The following subsections provide instructions for installing and running the HMI on Windows NT and UNIX systems.






6.3.1	 Windows NT





The Health Management Interface (HMI) runs as a service under Windows NT. After installation of the software release, the HMI is installed as a Windows NT service by running it with the -install option, as shown:


  C:\TEKTX\SOFT\UTIL> hmi -install
  NMS TX HMI installed.




Once the service has been successfully installed, the service must be started. This can be done by rebooting the system or as follows.


    


  1. From Control Panel, click the Services icon.
    

    

  2. Choose the NMS TX HMI service.
    

    

  3. Click START.
    




On subsequent system boots, the service is started automatically.


Note:  Before starting the HMI service, the HMI configuration file must be created or updated. See Section 6.2.1, HMI Configuration.





6.3.2	 UNIX





On UNIX, the HMI service is named hmid and runs as a daemon process. It can be started manually from a command line prompt or started at boot time from within a startup script. The hmid daemon has no command line parameters and generates no output messages.






6.4	 Bringing up a Redundant System 





Once the configuration steps are complete, and the HMI service has been started, the redundant system is started. To start a redundant system, the following steps are required:


    


  1. Start the txalarm utility.
    

    

  2. Load the first board and set to Primary state.
    

    

  3. Load the second board and set to Backup state.
    

    

  4. Start application traffic.
    







6.4.1	 Starting txalarm





The txalarm utility is the primary source for status information regarding communication problems between boards in a redundant configuration. Before starting the redundant system, it is important to start the txalarm utility to be able to monitor the startup and ensure that the system is working correctly. If you are running a dual node system, be sure to start txalarm on both systems. To run txalarm from an MS-DOS prompt (Windows NT) or a UNIX shell, type:



txalarm -f alarm.log



Messages will start displaying when the boards are first loaded. The -f option saves the output to a file for later reference.






6.4.2	 Loading and Setting Board States





These steps may be performed with the Redundancy Manager (RMG) sample application, or with a user application that uses the Health Management API (See Chapter 3 and Chapter 4).



For the rest of this section, it is assumed that the RMG sample application is used. 


 RMG on a Single Node system 



In a single node system, both boards of the redundant set are in the same machine. A separate instance of the RMG sample application must be invoked for each board of the redundant set.



rmg.exe is located in \tektx\soft\util for Windows NT, and /usr/bin for UNIX. Either directory should be in the path. See Appendix B for a full explanation of RMG and its parameters. 



One board is arbitrarily designated as node 1 of the redundant set. The other board is designated as node 2 of the redundant set. In this example, board 1 is node 1 and board 2 is node 2. Each RMG must also designate a UDP port over which to communicate with the other RMG. By default, this port number is 1700. However, since the boards are on the same machine, they must use different ports. So, for this example, the RMG for board 1 will use port 1700 and the RMG for board 2 will use port 1701.


    


  1. For the first board, type the following from an MS-DOS prompt:
    

        rmg -b 1 -n 1 -p 1701


    
For this example, board 1 (-b 1) is designated as node 1 (-n 1). Its local port is 1700 (default), and the port number of its mate is 1701 (-p 1701).
    

  2. For the second board, type the following:
    

        rmg -b 2 -n 2 -l 1701


    
For this example, board 2 (-b 2) is designated as node 2 (-n 2). Its local port is 1701 (-l 1701), and the port number of its mate is 1700 (default).
    
 RMG on a Dual Node system
    

    
Note:  To use RMG in a dual node system, both machines must have an IP network connection to the other board. This MUST BE a different connection from the Ethernet crossover that links the two TX boards. 




In a dual node system, each board of the redundant set is in a different machine. A separate instance of the RMG sample application must be invoked for each board of the redundant set.



The rmg.exe utility is contained in \tektx\soft\util for Windows NT, and /usr/bin for UNIX. Either directory should be in the path. See Appendix B for a full explanation of RMG and its parameters. 



One board is arbitrarily designated as node 1 of the redundant set. The other board is designated as node 2 of the redundant set. In this example, board 1 of machine A is node 1 and board 1 of machine B is node 2. To communicate with its mate, each RMG must also designate the IP address and UDP port of its mate. Since the boards are on separate machines, they can both use the default UDP port number, 1700.


    


  1. For the first board, on machine A, type the following from an MS-DOS prompt: 
    

        rmg -b 1 -n 1 -m 1.1.1.2


    
For this example, board 1 (-b 1), of machine A, is designated as node 1 (-n 1). Its partner is machine B, whose IP address is 1.1.1.2. Its local port is 1700 (default), and the port number of its mate is 1700 (default).
    
Alternatively, the host name of machine B could be specified with the -m command line option. Under Windows NT (with Microsoft Networking), or under UNIX, the host name may be used. 
    

  2. For the second board, on machine B, type:
    

        rmg -b 1 -n 2 -m 1.1.1.1


    
For this example, board 1 (-b 1) of machine B designated as node 2 (-n 2). Its partner is machine A, whose IP address is 1.1.1.1. Its local port is 1700 (default), and the port number of its mate if 1700 (default). 
    
Alternatively, the host name of machine A could be specified with the -m command line option. Under Windows NT (with Microsoft Networking), or under UNIX, the host name may be used. 
    
 RMG Startup
    




Each RMG, on startup, will attempt to load its designated board (if the board has not been already loaded). The load script used is defined in the HMI Configuration file (see Section 6.2.1).



The first node that starts RMG will become the primary node. For this example, it is assumed that Node 1 starts the RMG sample application first, which loads the board on Node 1 first, and then goes to the primary state. 



The RMG for Node 1 should display:


Board 1, Node 1  Board Loading
Board 1, Node 1  Now Starting
Board 1, Node 1  Board Isolated
Board 1, Node 1  Board Connected
Board 1, Node 1  Now Primary




It is assumed that Node 2 starts the RMG sample application second. So, Node 2 goes to the backup state.



The RMG for Node 2 should display:


Board 1, Node 2  Board Loading
Board 1, Node 2  Now Starting
Board 1, Node 2  Board Isolated
Board 1, Node 2  Board Connected
Board 1, Node 2  Now Backup




If both RMG applications display Now Primary, then the RMG applications are not communicating. See the Troubleshooting RMG Communication section.



If the Board Connected event is not displayed, then the boards are not communicating. See the Troubleshooting Board Communication section.


 Troubleshooting RMG Communication



If the RMG sample applications are not communicating, then both of the boards will go to the Primary state (i.e., the Now Primary message will display for both boards). If this occurs, check the following items:




If a Board Connected event is not displayed by either RMG, then there is a problem with the board to board connection.



The txalarm utility can be used to determine the board communication state. During a successful system startup, the inter-board communication status should become Connected, as shown in the following sample alarm output:


<05/14/1999 14:53:14> txmon  1    19745 Initialization complete
<05/14/1999 14:53:14> mtp    1        1 Configuring MTP Layer 1
. . .
<05/14/1999 14:53:14> mtp    1        1 MTP3: Ready...
<05/14/1999 14:53:14> txmon  1    19746 Task [mtp ] registered
<05/14/1999 14:53:14> txmon  1    19748 Mate board found at IP address
                                        64.0.21.132
<05/14/1999 14:53:15> mtp    1        1 MTP3 Connected
<05/14/1999 14:53:15> isup   1        1 Registering ISUP Layer
<05/14/1999 14:53:15> isup   1        1 ISUP: Ready...
<05/14/1999 14:53:15> txmon  1    19746 Task [isup ] registered
. . .
<05/14/1999 14:53:17> mtp    1    18179 MTP3 Link 0 Up




If the boards cannot communicate after being downloaded they will remain Isolated. During isolation, the signaling links terminated on the backup cannot be brought into service, and the backup board will not correctly reflect the state of the network. The most likely causes of isolation during turn-up of a new installation are:




Once the boards are properly connected, enter the status (S) command to each RMG. Each RMG should display the following status:


RMG Board n Status
---------------------------
State: Active
Heartbeats Sent: nnn       Received: nnn

HMI Board n Status
-------------------------
Heartbeats Sent: nnn        Received: nnn     Link State = Connected[1]

MTP State  = Primary[3]
ISUP State = Primary[3]




It is important to confirm that the State is Active and the Link State is Connected.






6.4.3	 Starting Data Traffic





Once boards are loaded and successfully communicating, normal data traffic can begin.



If links aren't established and/or data traffic is not successful, there may be a problem with the redundant MTP configuration. 


 Checking Link Status



The MTP link status can be checked to determine if the links are up. The mtpmgr application can be used to determine the link status. Section 6.2.3, MTP Configuration, provides a sample MTP configuration for each board having a single link to a third node at point code 2.2.2. Performing a status link * command for Node 1 for this configuration would produce the following results:


Num   Name     MTP3 State      MTP2 Hi State    Low State
0     T1       ACTIVE          ENABLED          IN_SERVICE
1     R        ACTIVE          REMOTE




Performing the same command for Node 2 would produce the following results:


Num   Name     MTP3 State      MTP2 Hi State    Low State
0     R        ACTIVE          REMOTE           
1     T1       ACTIVE          ENABLED          IN_SERVICE     




If the links are expected to be ENABLED and ACTIVE, but are not in this state, the MTP configuration must be checked.


 Checking MTP Configuration



Ensure that the proper MTP configuration file is being called from the proper ss7load script that is listed in the HMI configuration file. Also verify that links are configured with valid port types on the board they are physically terminated on and are configured as remote (R) on the mate board. For more information, see Section 6.2.3, MTP Configuration. 



If the port type appear to be configured correctly, but the links do not come into service, other problems may exist. See the SS7 Installation and Configuration Manual for more details on troubleshooting MTP configurations. 


 ISUP Testing 



Once both boards of the redundant set are loaded and communicating, and links are established, ISUP tests can take place using user applications, the sample applications orig and term (see the SS7 ISUP Developers Manual), or the isupdemo sample application (see Appendix C). 


 SCCP Testing



Once both boards are loaded and communicating, and the links are established, SCCP tests can take place using user applications, including the sample programs sccpdemo and (see the SS7 SCCP Developer's Manual).


 TCAP Testing



Once both boards are loaded and communicating, and the links are established, TCAP tests can take place using user applications, including the sample program find800 (see the SS7 TCAP Developer's Manual) or the redundant sample tcapdemo (see Appendix D).








 
    (Page 1 of 1 in this chapter)  Version




 




tech_support@nmss.com



Copyright © 2000, Natural MicroSystems, Inc.   All rights
reserved.