|
|
The Configuration Library Utility is the means by which the library of configuration files is maintained. Configuration files are flat files which contain unique information pertaining to customer data profiles and/or hardware and peripheral interfaces. To create configuration files, the user has the option of either using the TransPath system Configuration Tool (automated method) or going into the Configuration Library directly and using a UNIX text editor, vi, to modify the files (menu-driven method). Either procedure results in TransPath system Configuration Files that are saved in the Configuration Library. Changes made are saved in files that can be manipulated from a menu-driven program, Configuration Library Utility, designed to maintain versions of TransPath system Configuration Files.
The Configuration Library Utility is the program capable of storing multiple versions of the configuration files for the creation of new versions or for updating existing versions. In addition to the menu-driven approach, which accesses the Configuration Library directly, the Configuration Library Utility also supports an automated approach for configuring the TransPath system using the TransPath system Configuration Tool (TCT). The success of the procedure described below relies on the proper execution of the processes described in the TransPath System Configuration Tool Users Guide (see "Reference Materials").
The Configuration Library Utility is automatically distributed with the TransPath system software and no configuration is necessary. If the utility cannot find the Configuration Library, it prompts the user to create one. If the user replies affirmatively, the program saves the current files in the ./etc directory as the first entry in the version list under the heading CREATED FROM PRODUCTION.
Several commands are necessary to set up the config-lib script for initial use.
$host | DNS host name or IP address of the TransPath system Configuration Tool - This value needs to be in quotes ( |
$gctDir | Backup directory on the TransPath system Configuration Tool from which configuration files are retrieved. See the "Automated Procedure" section . |
$backupDir | Backup directory used in Main Menu items 7 and 8. It is defaulted to the home directory of the user currently executing the Configuration Library Utility. |
The configuration file library resides in a separate UNIX directory from the production directory. The production directory is where TransPath system programs look for the configuration data. The library directory, which is called the scratch area, is where files can be viewed and modified without affecting TransPath system execution. Only when the files are moved from the scratch area to the production area, are they available for TransPath system programs.
Each version of the Configuration Library is uniquely identifiable. Each is composed of a version which contains all configuration files. Configuration files are neither identified individually nor controlled separately.
Using the Configuration Library Utility is called the menu-driven procedure. This procedure is used for modifying or changing configuration files and is performed as follows:
Step 1 Start the Configuration Library Utility (see "Using the Configuration Library Utility" ).
Step 2 Check out a version to edit (see "MML Commands").
Step 3 Edit those configuration files that require changes (see "MML Commands").
Step 4 Check in or replace the version in the configuration library.
Step 5 Release the version to the production area.
Step 6 Perform the MML Change Configuration command to notify processes to read in the new configuration files.
To start the utility enter the following command line:
config-lib
At start-up, the Configuration Library Utility automatically performs the following checks:
1. Determines if a user is in the group, transpath. If not, the utility exits.
2. Determines if another user is already using the utility. If another user is using the Configuration Library Utility, the utility prompts whether or not to continue.
 | Caution Data loss can occur if multiple users attempt to access the same configuration files simultaneously. |
3. The following is displayed once the utility performs these checking operations:
TransPath Configuration File Library Main Menu
1.List Configuration Versions in Library
2.Check-out Configuration Library Version
3.Check-in Configuration Library Version
4.Replace Configuration Library Version
5.Release Current Library Version to Production
6.Save Production to Current Library Version
7.Backup Configuration Library
8.Restore Configuration Library
9.Enter Selection or q to quit
There are eight items on the main menu of the Configuration Library Utility and each item has a number and a corresponding function. Entering the item number at the selection prompt begins processing of the function. The functions are identified by their item number, as described below:
1. List Configuration Versions - displays a list of the configurations saved in the configuration library. For Example:
Configuration Versions
1. created from production Created at 97/05/14 12:53:27 2. Cisco Circuit 1 Created at 97/05/14 16:59:37 3. Telecom 14 Created at 97/05/22 16:36:39 4. production 9 circuit Created at 97/05/22 16:29:29 ***Currently Checked-out Version = Telecom 14
This screen shows that four versions are stored in the library. The version names are defined by the user when the version is checked-in, and a time stamp is automatically added. At the bottom, the currently selected version is displayed. The currently selected version is the configuration that is currently in use by the TransPath system. If there is nothing to the right of the equal (=) sign, there is no selected version.
2. Check-out Configuration Library Version - To work on an existing configuration file, use the Check-Out command. This is the ONLY way to select a version and make it the configuration used by the TransPath system. This selection displays the version list in the same format as menu item 1, and prompts the user to enter a version number. Enter a valid version number followed by the enter key and the files in the version are checked out of the configuration library and into the scratch area.
Type <q> and press the <enter> key to abort the selection.
3. Check-in Configuration Library Version - Creates a new library version and saves the current files from the scratch area into it. The user is prompted for a version. This name is displayed in subsequent version lists. It then asks for a comment string.
4. Replace Configuration Library Version - Performs the same function as the Check-in function but replaces an existing version rather than creating a new version. A list of versions is displayed in the same fashion as List Configuration Versions. Select a version and the utility replaces it in the version library.
Type <q> and press the <enter> key to abort the selection.
5. Release Current Library Version to Production - Copies the current version from the scratch area to the production area. Before copying takes place, a confirmation prompt is displayed.
6. Save Production to Current Library Version - Copies the configuration files from the production area to the scratch area. Check-in the version using Main Menu item 3 to save it.
7. Backup Configuration Library - saves the Configuration Library to the users local directory. This is used to save the library when a system upgrade, or an operation that might destroy the library, is to take place.
8. Restore Configuration Library - is not implemented yet.
Type <q> and press the <enter> key to exit the program.
The procedure which is used to administer files created by the TransPath Configuration Tool is called the Automated Procedure. The Automated Procedure for modifying or changing configuration files is as follows:
1. Start the Configuration Library Utility with two additional arguments, retrieve and "save name" as in the following example:
>config-lib retrieve ["save name"]
| Required argument to indicated the desire to start the automated procedure. |
| Optional argument to create a name to store the configuration files under. This name can be used later in the menu mode to retrieve this version of the configuration files. If this argument is not present, the version is called |
2. Perform the MML Change Configuration command to notify processes to read from the new configuration files (See "MML Commands" for a further description of the command).
3. An example MML command to add a new signaling path is:
mml> CHG-CFG:COMPONENTS&SIGPATH&SIGCHANDEV
This Configuration Library Utility automates the process of reconfiguring the TransPath system based on the configuration generated by the TransPath system Configuration Tool.
The TransPath system Configuration Tool is used to build and deploy the configuration files for the TransPath system installation.
The following procedure is only used when the TransPath system Configuration Tool functionality is not available nor is there failover. This procedure creates, modifies, and deletes provisioning table entries, e.g. signal channel pairings, parameters, etc. The procedure described in Using the Configuration Library Utility is used in conjunction with a UNIX text editor to manually modify the relevant table. To modify an existing TransPath system:
nedit text editor to edit the components.dat, sigPath.dat, bearChan.dat, and SigChanDev.dat files.
Details on modifying a specific aspect of the TransPath system configuration files is provided in the sections that follow in this manual. Once changes have been made to the Configuration Files, the operator executes the MML command CHG-CFG to perform a dynamic reconfiguration of the platform and invoke the changes on the platform without an interruption of service.
The data dictionary supplied in "Data Dictionary and Glossary" in this manual describes all of the file entries, purposes, and values on a per table basis. It also assists in associating what field entries are linked to other tables and entries within the configuration database directory.
Refer to the TransPath system "Installation and Configuration"
section to determine the path for configuration files. The first step is to enter the directory using the UNIX change directory command, cd. The default value for this is the TransPath /etc/CONFIG_LIB directory. An example command would be:
unix> cd /opt/TransPath/etc/CONFIG_LIB
Now the manual updating procedures as described in the sections that follow can occur. Once manual editing of the configuration files has been completed, move back to the directory from which you can run MML by entering the following command:
unix> cd /opt/TransPath/local
Use a text editor to make the necessary changes to the Platform ID and Network Element Information, based on the data provided in the Release P1.2.D data dictionary. Use the following command line:
>nedit components.dat
Use the procedures stated within this document to check out and check into the production library before and after changes are made to the file(s).
Each TransPath system Network Element (platform) can have a specific platform ID assigned to it. In addition, local system information, in the form of associated messaging, is produced on the platform. This enables remote element management command and response association to a specific platform in the network.
The MML command RTRV-NE displays the attribute of the TransPath system Network Element. You can review the TransPath system information by using the following MML command.
mml> RTRV-NE
Sample response:
CONFIG01/BUILD 13.6 97-05-15 15:08:09
M RTRV
Type=LPC
Hardware platform=XXX
Vendor=LightSpeed International, Inc.
Location= Sterling, Virginia
Version= Release 1.01.A
PStamp=paloalto970512202549
;
Use a text editor to make the necessary changes to the signal based on the information provided in the Data Dictionary. (see "Data Dictionary and Glossary"). Four files require modification when adding or deleting signal channel pairings from the system. Changes to existing signal channel parameters will only require an edit to the sigPath.dat table. Use the following commands:
Command line | >nedit components.dat |
Command line | >nedit sigPath.dat |
Command line | >nedit bearChan.dat |
Command line | >nedit sigChanDev.dat |
Use the procedures stated within this document to check out and check into the production library before and after changes are made to the file(s).
Use a text editor to make the necessary changes to the bearer channel mapping based on the information provided in the Data Dictionary (see "Data Dictionary and Glossary"). Use the following command line:
>nedit bearChan.dat
Use the procedures stated within this document to check out and check into the production library before and after changes are made to the file(s).
This procedure is intended for adding an E1 interface to the platform configuration database. The I/O card must be already inserted, and configured during initial install in order for this procedure to work. Use a text editor to make the necessary changes to the LIF (Line Interfaces) (E1) based on the information provided in the Data Dictionary (see "Data Dictionary and Glossary"). Use the following command lines:
Command line | >nedit components.dat |
Command line | >nedit auxsigPath.dat |
Use the procedures stated within this document to check-out and check into the production library before and after changes are made to the file(s).
The user with a TransPath system Configuration Tool and Failover will find that it is occasionally necessary to update their configuration. They may have added new customers, sites, or made other changes with the TransPath system Configuration Tool. Following are two methods for performing this procedure. One procedure is performed during a maintenance window and the other is performed while traffic is being carried (no maintenance window).
Step 1 Shut both systems down so that no TransPath system application software (including failover) is running.
Step 2 Perform a CONFIG-LIB SAVE or check-in to save the existing production configuration on both systems in the pair. This allows full recovery to the existing working configuration in the event of problems (see Menu Item Descriptions
).
Step 3 Perform a CONFIG-LIB RETRIEVE to download the new configuration to one system of the pair.
Step 4 Start the TransPath system software on the system upon which the CONFIG-LIB RETRIEVE was performed.
Step 5 Ensure that it is operational, processing traffic, and has established itself as the Master of the pair.
Step 6 If this system becomes operational, proceed to step 8.
Step 7 If this system does not become operational, follow the following steps:
(a) Stop this system by completely shutting down all software, including failover.
(b) Start the other system which has not as yet had it's configuration updated and return to Step 3.
(c) Investigate and correct the problem with the original system.
(d) Retry steps 3, 4, and 5.
Step 8 Start foverd and frepld on what is now the Slave or standby system. This will automatically replicate the new configuration data files from the Master to this system. Ensure it operates as the Slave.
Step 9 Roll the configuration as a commanded failover using cmd.failover.sh on the Master.
Step 10 Ensure the new Master becomes operational and runs traffic with the new configuration.
Step 11 Ensure that the Slave side is also operating correctly.
Procedure is now successfully completed.
Step 1 Perform a CONFIG-LIB SAVE or check-in to save the existing production configuration on both systems in the pair. This action allows full recovery to the existing production configuration in the event of problems.
Step 2 Perform a commanded failover with the OOS argument to stop frepld on the standby or Slave system in the pair (foverd is the only thing that should still be running). Ensure only foverd is running.
Step 3 Perform a CONFIG-LIB RETRIEVE to download the new configuration to the Slave or system in the pair.
Step 4 Perform a commanded failover from the Master system in the pair with the OOS argument. This action should stop all software on this system, with the exception of foverd. Ensure only foverd is operational.
Step 5 What was formerly the Slave side of the pair will now become the Master. Ensure that this system is operational and running traffic on the new configuration.
Step 6 If the Master system becomes operational, proceed to Step 8.
Step 7 If the new Master system does not become operational,
(a) Stop this system by performing a commanded failover with the OOS argument to completely shut down all software.
(b) Investigate and correct the problem and retry steps 3 through 6.
Step 8 Perform a commanded failover with the IS argument on what will become the new Slave side to restart frepld. Be sure that it remains the Slave and replicates the new configuration data files within itself.
Step 9 Perform a commanded failover.
Step 10 Verify that the new Master becomes operational and runs traffic with the new configuration.
Step 11 Verify that new the Slave side is correctly operational.
Procedure is now successfully completed.
Retrieving a configuration table listing while on line, and in the MML session, will aid the operator in instances where the actual "name" or "ID" parameter is required in the MML command. It serves as a reference retrieval on demand. See "MML Commands" for a more detailed description of this process.
The rtrv-cfg mml command displays the contents of a configuration table. The table can be any of the following: components, alarmcats, or meascats.
Example of a meascats command:
mml> rtrv-cfg:meascats
Sample response:
CONFIG01/BUILD 13.6 97-05-19 12:29:36 M RTRV LIF: SES SC: XMIT FRM TOT SC: RCV FRM TOT SC: RCV BAD CRC SC: RCV BAD TOT SC: RCV FRMR SC: RCV RESET DL: RCV UNSOL DL: RCV SABME DL: XMIT T200 DL: RCV SEQ DL: RCV FRMR RESP DL: RCV SIZE SP cInit in SP cInit out SP PDU in SP PDU out ;
The MML command chg-cfg sends a database change request to all processes registered for notification. The processes will re-load their runtime persistent databases.
Example chg-cfg command:
mml> chg-cfg:sigPath
Sample response:
CONFIG01/BUILD 13.6 97-05-19 12:32:59 M COMPLD ;
The Auxiliary Signaling Network is an out-of-band transmission path between TransPath system network elements to support the propagation of features across heterogeneous network topologies. The Auxiliary Signaling Network only needs to be configured as part of a function of Feature Transparency. If you do not have the Feature Transparency option, you do not need to configure the Auxiliary Signaling Network. Physically, the Auxiliary Signaling Network is an IP WAN or qualified Packet Network, within which virtual circuits are established between TransPath system network elements. This procedure describes the steps necessary to configure support for the Auxiliary Signaling Network on a TransPath system network element.
The following steps are necessary to configure and enable the ASN. Most of this information is provided in the configuration files distributed with the TransPath system software. For detailed descriptions of the configuration files, refer to "Data Dictionary and Glossary."
Step 1 Define a unique TransPath ID for the ASN in XECfgParm.dat (see "Failover Subsystem"). The TransPath ID is a 4 digit hexadecimal integer. This value MUST be unique for every TransPath system in a customer ASN.
For example:
Step 2 Define an Auxiliary Signaling Path (ASP) in components.dat. A common value for this is 000E0000 where 000E is the component type of ASP in compTypes.dat and 0000 is the first and only instance of it on the TransPath system. The following is an example line in components.dat:
If the ASP does not exist in components.dat, ASN access is disabled.
Step 3 Define the ASP Channel Controller process in components.dat, processes.dat, and dependencies.dat. The ASP Channel Controller is configured as any channel controller.
* Add an entry of type "Proc" to components.dat for the ASP. For example:
* Add an entry to processes.dat as part of the Cisco IOS Group. The software program name is "ASP". For example:
* Add an entry to dependencies.dat as part of the Cisco IOS Group. For example:
Step 4 Define the line interface to use for ASN connectivity in physLineIf.dat. This defines the provisioning characteristics for the line supporting the ASP connection. For example:
Step 5 Tie the ASP Channel Controller to the Line Interface in sigChanDev by adding an entry keyed by the ASP component ID, the Channel Controller ID, and the Line Interface/timeslot. For example:
Step 6 Add the TransPath system ID of the new TransPath system to auxSigPath.dat. This is a global table of all the TransPath systems in the Auxiliary Signaling Network. For example:
This file MUST be duplicated in its entirety on every TransPath system in the ASN.
sigPath.dat must be updated with the desired on-net and off-net table indexes for each of the signaling paths, using the ASN. This requires a virtual network ID and on-net/off-net feature table index to be added for those signaling paths using the ASN. See "Configuring Signal Paths for an Auxiliary Signaling Network"
for more information.
The VNET customer ID is a 4 character field set against the sigpath in sigPath.dat. It is an identifier name that is freely assignable by the network operator on a per customer basis, and is used to check whether the call type between two TransPath systems is on-net (if customer IDs match) or off-net (if they don't).
Also stored against the sigpath in sigPath.dat is a 4 character field in the format of "aabb" which is the VNET table index. The characters (aa) and (bb) must have characters in the range "00" to "99" and refer to on-net (aa) and off-net (bb) tables to be accessed, which are defined as constant feature profile tables in dpnss2_profiles.mdl.
The seven tables have been populated, such that a range of different allowances against different features exists. They are organized on a sliding scale where table 1 permits all features and table 7 permits none (or almost none). These tables can be easily modified, or new ones can be added according to customer requirements (although recompilation of DPNSS will be required). The current default is "0205" or "0206" depending on how off-net call forwarding is handled.
The indicator as to whether the sigpath is enabled to use ASN is the last character of the sigpath string.
Y | The |
N | The |
|
|