Port CPU Control
Three commands are available which relate to port CPU operation and are covered in the next three sub-sections.
Note: When connecting to chassis via TCL Server, always import IxTclServices after running "ixConnectToTclServer" and "ixInitialize" commands.
Port CPU Control
Each Ixia port that has a local CPU may be reset through the use of the portCPU reset command. Refer to portCpu for a full description of this command.
The port command’s isValidFeature sub-command may be used to determine if a given port has a CPU. Use the following sequence:
if [port isValidFeature $chas $card $port portFeatureLocalCPU] {
... port has a CPU ...
}
The important sub-commands and options of this command are mentioned in the following table:
Table: portCpu Sub-Commands
Member | Usage |
---|---|
reset |
Causes the port to reboot its operating system and return to its initial state. Any optional loaded packages are removed. The current port and stream configuration is not affected. |
Table: portCpu Options
Member | Usage |
---|---|
memory |
The amount of memory, expressed in MB, associated with the port. |
Issue Port CPU Command
Most intelligent Ixia port runs the Linux Operating system. Any Linux command may be remotely executed by TCL programming. The port command’s isValidFeature sub-command may be used to determine if a given port runs Linux. Use the following sequence:
if [port isValidFeature $chas $card $port portFeatureIxRouter] {
... port runs Linux ...
}
pcpuCommandService
The pcpuCommandService command allows commands to be sent to a set of ports and executed simultaneously. Different commands may be executed on different ports.
Refer to pcpuCommandService for a full description of this command. The important sub-commands and options of this command are mentioned in the following table:
Table: pcpuCommandService Sub-Commands
Member | Usage |
---|---|
add |
Adds a command to a specific port’s list. |
del |
Deletes a command from a specific port’s list. |
execute |
Sends commands to all ports and executes them. |
getFirst/getNext |
Cycles through list of ports and commands. Command results may be retrieved. |
Table: pcpuCommandService Options
Member | Usage |
---|---|
chassisID/cardID/portID |
The port being addressed. |
command |
The command to be executed (add) or executed (get). |
input |
Optional lines of text that is used as the command’s standard input stream. |
output |
The text from standard output from the executed command. A maximum of 1024 bytes is saved. |
error |
The text from standard error from the executed command. A maximum of 1024 bytes is saved. |
result |
The result code of a command’s execution. In general zero means no error and a non-zero indicates an error. |
A high-level command, issuePcpuCommand, is also offered.
serviceManager
Most intelligent Ixia ports run the Linux Operating system. Software may be developed for these ports using the guidelines documented in the Ixia Linux SDK Guide. Such software must be combined in a set of files called a package and downloaded to a set of ports. Software packages must have been previously placed on the chassis associated with any affected port, in the following folder:
C:\Program Files\Ixia\packages\
The following files constitute a package:
- A control file: This file, with the extension ini, allows different data files to be downloaded to the ports based on the type of port processor and operating system version. All ini files must be located in the C:\Program Files\Ixia\packages\ folder.
- Data files: One or more data files, each specifically compiled for a specific CPU type and/or operating system. Data files are typically organized in separate folders:
<package>/<processor>/package.tgz
For example, a package named sample which supports the PPC 405 and 750 processors would have the following files:
C:\Program Files\Ixia\packages\sample.ini
C:\Program Files\Ixia\packages\sample\ppc405\sample.tgz
C:\Program Files\Ixia\packages\sample\ppc750\sample.tgz
Control File Format
Each package must have a control file named <package>.ini, where <package> is a unique name. The following types of statements are allowed in a control file:
- autoload. This is a single, optional statement:
- package. A package statement is of the form:
- processor. This is matched against the type of CPU running on the port. The legal values are as follows:
- ppc405: Power PC, model 405.
- ppc750: Power PC, model 750.
- sh4: Hitachi SH4.
- platform. This is matched against the version of IxOS software running on the port. The legal values take the following forms:
- version: This version only.
- -version: Up to and including this version.
- version-: From this version on.
autoload=1
If present, this indicates that the associated package is to be loaded onto all port CPUs and started as per the indicated by the packages start.sh file, discussed below. This statement should only be used if it really necessary for a package to permanently reside on a port.
package [name=value, [...]] path=<package path>
One or more name=value pairs may be used to qualify the condition under which a particular version of the software is used. The possible name values are:
A version is of the form n.n[.n...]. That is, two or more decimal separated numbers. For example, 3.65 or 3.70.24.9.
An example ini file is shown below:
#sample.ini
package processor=ppc405, path=sample/ppc405/sample.tgz
package processor=ppc750, platform=3.65-3.70, path=sample/
ppc750/sampleOld.tgz
package processor=ppc750, platform=3.80, path=sampleNew.tgz
Data Files
The data files associated with a package are contained in a single gzipped tar file. The Linux command line to create such a package is as follows:
tar -czf <package>.tgz <file1> <file2> ...
The files in the tar file is unpacked on each processor to the following:
/opt/<package>
folder. The following types of files are contained in the tar file:
- start.sh: This file is mandatory and describes how to install and start the package. It is automatically run as soon as the package is downloaded to a port by /bin/sh start.sh from /opt/<package>. For example, if a tar file contained the following files:
- start.sh
- stop.sh
- bin/sample
- lib/libsample.so
- stop.sh: This optional file is run by the service manager prior to deleting the package’s files in /opt/<package>. This script should kill any processes that the start.sh script spawned and remove any files that were installed outside of /opt/<package>.
- executable files: Although the files may be organized in any manner, we suggest that the package’s main executable be placed in a bin folder and that any library be placed in a lib folder.
Then an appropriate start.sh would be:
#start.sh
# Symlink to /bin and /lib
ln -s ../opt/sample/bin/sample ../../bin
ln -s ../opt/sample/lib/libsamble.so ../../lib
/bin/sample > /dev/console 2>&1
serviceManager
The serviceManager command is used to download and manage packages. Refer to serviceManager for a complete explanation of these sub-commands. Note the serviceManager command is valid in Windows based environments.
The important sub-commands of this command are mentioned in the following table:
Table: serviceManager Sub-Commands
Member | Usage |
---|---|
downloadPackage |
Downloads and starts a package to the ports associated with a port group. The port group is built using the portGroup commands. |
deletePackage |
Stops and deletes a package from the ports associated with a port group. |
getInstalledPackages |
Returns a list of packages installed on a particular port. |