Cisco Application eXtension Platform 1.1 User Guide

Revised: 8/25/08, OL-14815-01

This guide describes the commands and tasks for installing and configuring the Cisco Application eXtension Platform (AXP) on Cisco's Integrated Service Routers. For more information on Cisco AXP, go to www.cisco.com/go/axp

For a list of features added in the latest Cisco AXP release, refer to the following document:

Overview

The Cisco Integrated Services Router (Cisco ISR) is an integrated system within a single chassis. The Cisco ISR ties together and runs multiple value-added services such as voice, layer 2 switching, security and application acceleration. In addition, integrated services can be hosted within Cisco OS software or decoupled and hosted on modular application service modules.

The Cisco ISR allows for blade hardware plug-in network modules. These application service modules enhance the functionality, intelligence and flexibility of the router. The Cisco Application eXtension Platform (Cisco AXP) provides the tools required by third party developers to integrate their applications on Cisco ISRs.

Cisco AXP allows third parties such as system integrators, managed service providers, and large enterprise customers to extend the functionality of Cisco ISRs by providing their own value-added integrated services. On the application service module, Cisco AXP hosts applications in a separate runtime environment with dedicated resources. In addition, Cisco AXP provides Application Programming Interfaces (APIs) so that functions such as packet analysis, event notification, and network management can be utilized by hosted applications.

Cisco AXP consists of the facilities and frameworks to host applications, and service APIs for integrating applications into the network.

Cisco AXP provides the following features:

•Ability to modify the Cisco IOS software configuration and obtain the status of Cisco IOS software features via the provided API.

•Embedded Linux environment supporting the execution of applications written in the following programming languages: Java, C (native), Perl (interpreted), Python (interpreted), and Bash (interpreted). Native and interpreted applications written in other programming languages can be integrated by the application vendor if the vendor uses additional support libraries and interpreters.

•Integration of virtual devices.

The Cisco IOS auxiliary serial port can be virtualized, appearing as a local device in the Cisco AXP OS. The application controls external peripherals attached to the auxiliary serial port of the router without special knowledge of where the device is located.

•Predictable and constant set of application resources.

These resources (including CPU, memory, and disk) are segmented, which ensures that the application and router features work independently, and without interference.

•Protection of the router and applications from rogue applications.

If an application crashes, this incident does not affect the router or other applications, because of the installed application being placed in its own virtual instance.

•Protection against running unauthorized software.

Only Cisco certified parties can install software on Cisco AXP.

•Robust debugging and troubleshooting facilities.

•Support of event notification.

An application can receive the status of the Cisco ISR and take appropriate action.

Note For a more detailed overview of Cisco AXP, see the Cisco AXP Developer Guide.

Initial System Setup

To set up your router and Cisco AXP service module:

1. Verify that the service module SKU matches the Cisco ISR and install the router and service module. Refer to the "Supported Hardware" section.

•IP address or name of the FTP server that will store the Cisco AXP package file.

•Verify that the FTP server is accessible

SUMMARY STEPS

1. Download the Cisco AXP files.

Note If you choose to use a file extractor tool designed for Windows, such as WinZip, you must disable CR/LF conversion of tar files. (For example, in WinZip 9.0 select Configuration > Miscellaneous and uncheck "TAR file smart CR/LF conversion".)

2. Copy the files to the FTP server. All files to be installed must reside in the same directory.

Application Software Versions

Each application has a version number, which is used by the Installer when resolving dependencies between subsystems. The system only considers the first two digits of the version number for checking dependencies.

The first digit is treated as a major version number and the second is treated as a minor version number. For example:

Version 1.2.3.4 has a major number of 1 and minor number of 2.

Version 5.6 has a major number of 5 and minor number of 6.

Version 1.2.3 is considered the same as Version 1.2 or Version 1.2.3.4 because both the major and minor numbers match.

Cisco AXP Command Modes

This section includes the procedures listed below for entering and exiting the command environment, where Cisco AXP software configuration commands are executed.

•Configuration command choices are similar to those that are available on the router. Access global configuration mode by using the configure terminal command.

•Enter configuration commands.

•Exit global configuration mode with the exit command and save your new configuration with the copy running-config startup-config command. Notice that you do not use the enable command and the prompt does not change from >.

Step 5

Press Control-Shift-6x.

Suspends the service-module session and returns to the router CLI. Alternatively, type the exit command to return to the router CLI.

Note The service-module session stays up until you clear it in the next step. While it remains up, you can return to it from the router CLI by pressing Enter.

From the Host-Router CLI

Step 6

service-module integrated-service-engineslot/0session clear

Example:

Router# service-module integrated-service-engine 1/0 session clear

Clears the service-module session for the specified module. When prompted to confirm this command, press Enter.

Setting Resource Limits

Cisco AXP provides a predictable and constant set of resources such as CPU, memory, and disk space, which are segmented to allow an application to run on the Cisco AXP service module without affecting the performance of other router features. You can specify CPU, memory, and disk space limit (specified in MB), using the CLI with administrator privileges.

For information on the CPU index for Cisco AXP service modules, refer to the following section in theCisco AXP Developer Guide:

Use the axp-helper-k9.<aim/nme>.<release-number> rescue helper image file to aid software installation of the Cisco AXP host OS files on an AIM or NME service module when necessary. Installing software using the helper image overwrites all previously existing data on the service module.

Cisco AXP Upgrade and Downgrade Scenarios

This section describes the various types of upgrades and downgrades that are supported on Cisco AXP.

Downgrade Scenarios

Resource Limits Exceeded after Downgrade

The following scenario may occur after downgrading an application on Cisco AXP.

If the current software on the service module is App V2 with Cisco AXP host OS 1.1.1, and a downgrade is performed to a lower version of Cisco AXP host OS (for example, 1.0.6) using App V1, the files for App V2 may still be present on the application service module.

The presence of two versions of the application may cause resource limits to be exceeded. Error messages may be displayed when trying to run App V1 (referenced as APP1 in the error message) on Cisco AXP host OS (1.0.6):

Installs the Cisco AXP host OS (platform) file that was downloaded on the FTP server.

package-filename— A single file or a bundle of files.

ftp-server-ip-address— FTP server address where the package is located.

package-filename— Cisco AXP package file name

username—FTP server ID/username

password—FTP server password

Note:

If an error displaying a mismatched sum occurs during installation, use the software removeall command to remove all residual files, and reinstall the files using the software install clean command. Refer to Removing Software.

Step 2

exit

Exits EXEC mode.

Clean Software Installation including FTP Server Configuration

To configure the FTP server and install software, perform the following steps.

Using this command restores saved configurations. When a new software release is installed over an existing one, the old installer from the previous release is first upgraded via the package, axp-installer-k9.<nme/aim.1.0.x>.<1.0.x>.prt1, and then the new image is installed.

Step 3

exit

Exits EXEC mode.

Downgrading Software

The software install downgrade command is not supported.

To downgrade Cisco AXP software to a lower release, use the same command for upgrading software:

software install upgrade.

Installing Software using a Helper Image

If the service module does not boot up with the regular image you can install software using a helper image. To use the boot helper to reboot with a helper image, perform the following steps.

Note•Configure the router before setting up the bootloader. The service module will not connect to the external network if the router is not configured correctly. If you have not configured the bootloader, see the "Configuring the Bootloader" section.

•Using the helper image for installation clears the startup configuration to the factory default settings. All previous configuration settings are erased.

Step 1 Enter the following commands from the router CLI:

a. service-module Service-Engine 1/0 reset (wait about 10 seconds after using this command).

b. service-module Service-Engine 1/0 session (repeat this command if the first try fails).

Note For the Default Helper-file name, if you are pasting in the name, do not paste any extra whitespaces (newline, tabs) into the name. If whitespaces are included, they will also be present in the image name that is requested from the TFTP server.

Default Helper-file—name of the helper image.

Ethernet interface—internal

Note The internal interface is facing the router. The external interface may or may not be present on the service module.

External interface media—copper

Default Boot—disk

Default bootloader—secondary

Note Always use the secondary bootloader; the primary bootloader is only for backup.

Step 4 Enter the show config command from the bootloader to verify that there are no empty values. (Check for any null/empty values as these may cause problems with the network boot sequence.)

SE- boot-loader> show config

Note Before entering the boot helper (in step 5), do the following:

•Check that the IP address you entered in step 3 is the IP address of the service module as configured on the host router.

•Check that the TFTP server you entered in step 3 has connectivity to the service module. For example:

SE- boot-loader> pingTFTP-server-address

Step 5 To enter the boot helper, type: boot helper

The helper image starts and the following text appears:

Welcome to Cisco Systems Service Engine Helper Software

Please select from the following

1 Install software

2 Reload module

3 Disk cleanup

(Type '?' at any time for help)

Select 1 Install software:

Step 6 Enter the following parameters:

Package Name—Cisco AXP package name

Server URL—FTP server location for the Cisco AXP package

Username—FTP username

Password—FTP password

Step 7 Enter y (yes) to clear disk contents.

After installation, the blade reboots with the new image.

Troubleshooting the Boot Helper File

Use a workstation to download the boot helper file from the TFTP server. This verifies that the TFTP server is running, the requested helper file exists, and there are no file access errors. File access errors are not displayed in boot helper.

Removing Software

To remove software, use the software uninstall command in Cisco AXP EXEC mode.

SUMMARY STEPS

1. software remove

2. exit

DETAILED STEPS

Command or Action

Purpose

Step 1

software remove {all|downgradefiles|downloadfiles

Example:

SE-module> software uninstall

Removes software files during a clean installation, upgrade, or downgrade.

all—Removes all files

downgradefiles—Removes all files that have been downgraded.

downloadfiles—Removes all files that have been downloaded.

Step 2

exit

Exits Cisco AXP EXEC mode.

Uninstalling Software

To uninstall software, use the software uninstall command in Cisco AXP EXEC mode.

SUMMARY STEPS

1. software uninstall

2. exit

DETAILED STEPS

Command or Action

Purpose

Step 1

software uninstall uid-list

Example:

SE-module> software uninstall

Uninstalls the Cisco AXP package files.

uid-list—List of unique identifiers(UID) of sub-systems to be uninstalled

Step 2

exit

Exits Cisco AXP EXEC mode.

Secure Shell Access to the Service Module

For direct secure shell (SSH) access to the Cisco AXP CLI, a user must first session into the service module and configure it.

This initial configuration gives users direct SSH access to the Cisco AXP CLI and also allows them to perform remote configurations without constantly accessing the router and sessioning into the service module.

Cisco AXP provides secure shell (SSH) access to the CLI through a default user that acts like a system administrator. The password for the default system administrator must be configured by the user through the CLI, before SSH access to the Cisco AXP CLI. This password must be at least five characters.

If service password encryption is enabled, the system encrypts the clear text password that is entered and saves it in the encrypted format in the configuration file. If the user prefers a clear text password, service password-encryption is disabled by entering the no form of the command.

This command directs the system to encrypt the password using a system provided two-character salt string. With this service enabled, a clear text password string is encrypted and displayed as a level 7 password string.

Configuring Password Protection

To session into the service module for direct SSH access to the Cisco AXP CLI and to configure the password, perform the following steps.

1. Session into the service module and configure the password.

2. service password-encryption password encrypts the clear text password that is entered and saves it in the encrypted format in the configuration file.

SUMMARY STEPS

1. configure terminal

2. service password-encryption

or,

no service password-encryption

3. username sysadmin passwordclear-password-string

or,

username sysadmin password 0clear-password-string

or,

username sysadmin password 7hashed-password-string

4. exit

DETAILED STEPS

Command or Action

Purpose

Step 1

configure terminal

Enters global configuration mode.

Step 2

service password-encryption

Encrypts the clear text password using a system provided two-character salt string. The password is saved in the encrypted format in the configuration file.

A clear text password string is encrypted and displayed as a level 7 password string.

no service password-encryption

To keep the clear text password, then disable the service password-encryption command with the no prefix.

Step 3

username sysadmin passwordclear-password-string

You can use either one of these three commands:

Specifies a non encrypted (cleartext) user password.

username sysadmin password 0clear-password-string

Specifies a non encrypted password.

username sysadmin password 7hashed-password-string

Specifies a hidden password.

Step 4

exit

Exits configuration mode.

Configuring the SSH Server

To configure SSH access to the CLI server allowing remote access to the Cisco AXP service module, perform the following steps.

SUMMARY STEPS

1. configure terminal

2. ip ssh server

3. ip ssh interfaceinterface

4. exit

DETAILED STEPS

Command or Action

Purpose

Step 1

configure terminal

Enters global configuration mode.

Step 2

ip ssh server

Enables the SSH service (starts the sshd daemon). Default SSH service is enabled.

If the sshd daemon is running when you configure the no form of the command: the sshd daemon stops, the existing SSH session remains alive, and no new SSH sessions are accepted.

Step 3

ip ssh interfaceinterface

Specifies the interface on which sshd should listen for an incoming connection.

If you do not use this command, sshd listens on all interfaces.

If sshd is configured to listen to a specific network interface, an IP address change for that interface prevents SSHD from accepting a connection on that modified interface.

You must restart sshd or the Cisco AXP service module to re-establish SSH service.

Step 4

exit

Exits global configuration mode.

Verifying the SSH Server

To verify the SSH service is running, perform the following steps.

SUMMARY STEPS

1. show processes

2. show processes memory

DETAILED STEPS

Command or Action

Purpose

Step 1

show processes

View the state of the SSHD process. For this command and other diagnostic commands see Table 9.

Step 2

show processes memory

In EXEC mode, display the information of the sshd process when it is running.

Configuring the Syslog Server

Configuration of a syslog server allows the Cisco AXP service module to collect log messages from other physical and virtual devices on the network. The syslog server binds to an interface to accept log messages from any source on the network.

A user can enable or disable the syslog server on the Cisco AXP service module, and can specify the maximum log file size limits that can occupy the local file system space.

Because the syslog server cannot be configured to filter logs based on facility or priority, all log messages must be filtered before they are sent to the syslog server.

Log files generated by the syslog server reside in the /var/remote_log directory, and the log file is named remote_messages.log. Rotated log files are appended with a number, such as remote_messages.log.1, with the higher numbers designating older files. The oldest log file is deleted during a file rotation.

SUMMARY STEPS

1. configure terminal

2. syslog-server

3. syslog-server limitfile-rotationsize [file-size num]

4. syslog-server limitfile-size size [ file-rotation num ]

5. exit

DETAILED STEPS

Command or Action

Purpose

Step 1

configure terminal

Enters configuration mode.

Step 2

syslog-server

Enables or disables the syslog server.

The syslog server is disabled by default.

If the server is enabled, the Cisco AXP service module is used as a syslog server to receive all the log files from external devices.

A error message:

ERROR - system does not have enough disk space

appears if:

•The system has less than 80G disk storage,

or,

•Available disk space does not satisfy the current limits set by file size, and the number of files.

Resolve error by either unloading applications to free disk space, or by changing limits.

If this error occurs you cannot enable the syslog server.

Step 3

syslog-server limitfile-rotationsize [file-size num]

Sets syslog server limits.

file-rotation-—Defines the number of log files to be rotated. The range is 1 to 40 and the default is 10.

file-size—Defines the maximum size (in MB) of each log file. The range is 1 to 1000 MB and the default is 20 MB.

Setting the file rotation configuration lower than the current settings causes extra log files to be deleted.

Example

If the current file rotation value is 5 and the new file rotation value is 2, log files 3 to 5 are deleted.

A message,

WARNING - setting the new file-rotation value to 2 from the old value of 5 caused extra log files to be removed

notifies the user if they have specified a new file rotation value that is lower than the current file rotation value.

Error messages:

Error Message System does not have
enough disk space.

This error occurs if the available system disk space is not enough to satisfy the new configured limits.

The file rotation and file size error messages appear if you enter an invalid value for a configuration. For example if you enter 80001 as the file-size or 99 as the file-rotation.

The invalid values are rejected and the original limit values remain effective.

Error Message File-rotation is out of
range (1-10).

Error Message File-size is out of range
(1-80000).

Step 4

syslog-server limitfile-size size [file-rotation num]

Sets syslog server limits.

file-rotation-—Defines the number of log files to be rotated. The range is 1-40 and the default is 10.

file-size— Defines the maximum size (in MB) of each log file. The range is 1-1000 MB and the default is 20 MB.

Setting the file rotation configuration lower than the current settings causes extra log files to be deleted.

Example

If the current file rotation value is 5 and the new file rotation value is 2, log files 3 to 5 will be deleted.

A message,

WARNING - setting the new file-rotation value to 2 from the old value of 5 caused extra log files to be removed

notifies the user if they have specified a new file rotation value that is lower than the current file rotation value.

Error messages:

Error Message System does not have
enough disk space.

This error arises if the available system disk space is not enough to satisfy the new configured limits.

The file rotation and file size error messages are displayed if an invalid value is entered for a configuration. For example if you enter 80001 as the file-size or 99 as the file-rotation.

The invalid values are rejected and the original limit values remain effective.

Do not remove a built-in physical interface. Upon removal, an error message appears:

Error Message Can not remove the built-in
interface eth0/1.

Step 3

ip addressip-addressnetwork-mask

Configures the IP address and network mask for the specified network interface.

Changing the IP address for a bound interface results in a message warning the user that the application is bound to the interface.

To remove the old IP configuration, reset the virtual instance.

Step 4

exit

Exits interface configuration mode.

Step 5

app-service application-name

Enters application service configuration mode.

Step 6

bind interface network-interface-name

Attaches or detaches a networking device to or from the application environment.

network-interface-name—Interface name defined in the host, for example, the Ethernet device-name defined in the interface command.

The interface is immediately available to the virtual instance with the execution of a new bind command.

Note This command modifies configuration entries in the /etc/hosts file for ipaddr and hostname mapping.

ipaddr in the /etc/hosts file is modified when the command is issued. Only the first interface binding is used. Since eth0 is the default to be bound for each virtual instance, ipaddr is normally eth0.

Step 7

end

Ends configuration mode.

Step 8

app-service application-name

Enters application service mode.

Detaching a Networking Device from the Application Environment

To remove a networking device to/from the application environment, perform the following steps.

SUMMARY STEPS

1. configure terminal

2. app-service application-name

3. no bindinterface network-interface-name

4. end

5. app-service application-name

6. reset

DETAILED STEPS

Command or Action

Purpose

Step 1

configure terminal

Enters global configuration mode.

Step 2

app-service application-name

Enters application service configuration mode.

Step 3

no bind interface network-interface-name

Detaches a networking device from the application environment.

network-interface-name—Interface name defined in the host, for example, the Ethernet device-name defined in the interface command.

Detaching an interface binding displays the following warning messages,

WARNING!!! Reset the hosting environment

WARNING!!! For binding to be removed

and requires a virtual instance to restart.

Note The networking device is only detached after the final reset command.

Step 4

end

Ends configuration mode.

Step 5

app-service application-name

Enters application service mode.

Step 6

reset

Resets the hosting environment.

Configuring a Virtual Interface

To configure a virtual interface, perform the following steps.

SUMMARY STEPS

1. configure terminal

2. interface eth0:x

3. ip addressip-address

DETAILED STEPS

Command or Action

Purpose

Step 1

configure terminal

Enters global configuration mode.

Step 2

interfaceeth0:x

Configures the virtual interface. Enters interface sub mode.

x—Interface number.

Note The colon (":") indicates this is a virtual interface.

Step 3

ip address ip-address

Configures the IP address.

Configuring a VLAN Interface

VLAN needs to be configured on the router and Cisco AXP sides. In the configuration for the router configuration in step 3 below, the dot "." in "port.x" indicates a sub interface. Refer to Table 3 for virtual and VLAN naming differences.

Note Configuring a VLAN interface is not supported on Cisco AXP AIM service modules.

To configure an appropriate route for the Cisco IOS software to set up traffic to the VLAN interface, it is necessary to configure the interface to DOT1Q mode.

DOT1Q mode only affects traffic that flows through this interface; it does not inject the VLAN tag for end-to-end traffic. If no native VLAN is configured on an interface, Cisco IOS by default makes encapsulation 1 DOT 1Q the default native VLAN.

On the Cisco AXP service module, VLAN ID 1 is always the native interface.

Note It is not possible to ping the Cisco AXP service module from the router when using encapsulation 1 on the router, with a subinterface on the service module that has a matching native VLAN ID of 1 (eth0.1).

Recommendation

Try using a VLAN ID greater than 1 if it is not necessary to use VLAN ID 1 in your network. If you must use VLAN ID 1, add a native command to another DOT1Q interface and then use VLAN ID 1 as shown in the "VLAN Configuration Example" section.

To configure a VLAN interface, perform the following steps.

SUMMARY STEPS

1. On the router side:

configure terminal

ip routing

interface Integrated-Service-Engineslot/port.x

encapsulation dot1qvlanid

ip addressip-address

2. On the Cisco AXP Service Module:

configure terminal

interfaceethport.x

ip addressip-address

DETAILED STEPS

Command or Action

Purpose

On the router side:

Step 1

configure terminal

Enters configuration mode.

ip routing

Enables IP routing on the router.

interface integrated-service-engineslot/port.x

Enters interface sub mode.

x—Interface number.

Note Use a value of x greater than 1.

encapsulation dot 1Qvlanid

Defines the encapsulation format as IEEE 802.1Q (dot1q), and specifies the VLAN identifier.

Configuring the NTP Server Source

To have a consistent set of time stamps required for logs and development authorization between the router and the AXP service module, an administrator must configure the Cisco AXP service module to receive its NTP clock source from the router.

For Cisco AXP 1.0.5 and higher releases, the service module can immediately synchronize with the router. For this synchronization, the router must be set as the master NTP server using the ntp master command.

The ntp master command sets the router as the master source for providing clock synchronization, using its own system clock as the source for itself and the Cisco AXP service module.

However, in many cases, the router can also use another trusted NTP server as its source. Use the ntp server command to set an external server as the source for clock synchronization.

Note The time zone setting is not automatically passed from the NTP master to the client, if they are set in different time zones.

For additional documentation on NTP, refer to the following link on Cisco.com:

Verifying NTP Server Configuration

Use the show clockdetail command to verify the clock settings on the router and the AXP service module.

SUMMARY STEPS

1. On the router:

show clockdetail

2. On the AXP service module:

show clockdetail

DETAILED STEPS

Command or Action

Purpose

Step 1

On the router:

show clock detail

Example:

Router# show clock detail

00:24:02.669 UTC Sat Oct 27 2007

Time source is NTP

Displays clock settings on the router.

Step 2

On the AXP service module:

show clock detail

Example:

se-Module> show clock detail

16:43:30.616 PDT Fri Oct 26 2007

time zone: America/Los_Angeles

clock state: unsync

delta from reference (microsec): 0

estimated error (microsec): 16

time resolution (microsec): 1

clock interrupt period (microsec): 10000

time of day (sec): 1193442210

time of day (microsec): 619436

Displays clock settings on the AXP service module.

Configuring the Hostname

Configure the hostname for the application using the commands shown below.

SUMMARY STEPS

1. configure terminal

2. app-service application-name

3. hostname hostname

DETAILED STEPS

Command or Action

Purpose

Step 1

configure terminal

Enters global configuration mode.

Step 2

app-service application-name

Enters application service mode.

Step 3

hostnamehostname

Configures the hostname for the application.

The hostname is limited to 32 characters.

If you enter more than 32 characters an error message appears:

Error Message hostname size greater than 32

Note If hostname is not configured, the default hostname on the host side is used.

This command modifies configuration directives in /etc/hosts and updates the hostname of the hostname-ip mapping entry.

If the file does not exist, the command creates the /etc/hosts file, and adds an entry into the file.

If the file exists, (for example, if an application package has already bundled its own /etc/hosts file), the new entries are appended to the existing entries and the original entries remain intact.

The ipaddr in the /etc/hosts file is modified when you use the bind interface command. The first interface binding is used.

The ipaddr is usually eth0 because eth0 is the default, and is bound to each virtual instance.

Example:

/etc/hosts:

10.0.0.1 localhost.localdomain localhost ##
added by cli

ipaddr hostname.domain hostname ## added by
cli

Configuring the Application Domain

Using the ip name-server and ip domain-name commands in the host populates the /etc/resolv.conf file in each installed virtual instance. Using these commands to change the configuration in the host results in the /etc/resolv.conf file being updated.

When these commands are used to configure a new name-server and domain-name for a virtual instance (in app-service mode), the /etc/resolv.conf file in that virtual instance is overridden with the new server name and domain name.

The /etc/resolv.conf file in that virtual instance reverts back to the host configuration whenever the virtual instance does not have a name-server or domain-name configured.

Configuring the name-server and domain-server in a virtual instance always takes precedence over configuration in the host.

DNS Address

To configure the address of the domain name server (DNS) for the application, perform the following steps.

SUMMARY STEPS

1. configure terminal

2. app-service application-name

3. ip name-server ip-address

DETAILED STEPS

Command or Action

Purpose

Step 1

configure terminal

Enters global configuration mode.

Step 2

app-service application-name

Enters application service mode.

Step 3

ip name-server ip-address

•ip-address: IP address of the DNS.

•Configures the IP address of the domain name server (DNS) for the application.

•A maximum of two DNS servers can be defined.

In a Linux environment, the /etc/resolv.conf file typically contains the IP addresses of name servers (DNS name resolvers) that attempt to translate names into addresses for any node available on the network.

This command creates the /etc/resolv.conf file and adds the name-server entries in it if the file does not exist.

If an application package has already bundled its own /etc/resolv.conf file, the new entries are appended to the existing ones and will leave the original ones intact.

Example:

search localdomain ## added by cli

domain localdomain ## added by cli

nameserver x.x.x.x ## added by cli

Domain Name

To configure the domain name for the application, perform the following steps.

SUMMARY STEPS

1. configure terminal

2. app-service application-name

3. ip domain-name domain name

DETAILED STEPS

Command or Action

Purpose

Step 1

configure terminal

Enters global configuration mode.

Step 2

app-serviceapplication-name

Enters application service mode.

Step 3

ip domain-namedomain name

Configures the domain name for the application.

The domain-name is limited to 64 characters.

If more than sixty four characters are entered, the following error message is displayed:

Error Message domain size greater than 64

Default: The domain name is not configured.

This command modifies configuration directives in /etc/hosts and /etc/resolv.conf files where the domain name is relevant.

This command also modifies the search list for hostname lookup and domain directives for local domain name in /etc/resolv.conf file.

For /etc/hosts file, it updates the domain name of the hostname-ip mapping entry.

Example:

/etc/resolv.conf:

search cisco.com ## added by cli

domain cisco.com ## added by cli

nameserver x.x.x.x ## added by cli

/etc/hosts:

10.100.50.10 appre.cisco.com appre

Configuring Console Access

Use the connect console command to access the guest OS shell. To enable the connect console command, first obtain console access using the postinstall script. Refer to the section, Obtaining Console Access for the Application in the Cisco Application eXtension Platform Developer Guide.

To configure console access, perform the following steps.

SUMMARY STEPS

1. app-service application-name

2. connect console

DETAILED STEPS

Command or Action

Purpose

Step 1

app-service application-name

Enters application service mode.

Step 2

connect console

Allows a third party to integrate their own application commands to the console shell.

On initiating the command, /bin/console executes.

The third party application must provide its own console file in binary or as a script (telnet to their CLI), to cross connect to their CLI shell.

If the application does not provide a console file, the following message appears:

You can specify multiple route lines in a configuration and use the show ip route command to display the configured routes saved in the database. Some routes are added by default when configuring the interface. The default route for eth0 is configured through the Cisco IOS software CLI.

Source-based IP Routing

Source-based IP routing, also known as static route configuration, is necessary for application initiated data transfer, such as client applications, and is used to determine an outbound interface when multiple interfaces are bound to an application instance.

Source-based routing is implemented for server applications to route response packets back through the incoming interface, and it is independent of the destination address.

Consider traffic entering the Cisco AXP service module through an ethernet interface, for example eth0.20, from an external IP address X. When the Cisco AXP application generates a reply, the system now contains a packet with source IP address, which is the address for eth0.20, and the destination IP address X.

If source-based routing is not applied, this packet is sent to a default route through eth0. Source based routing routes traffic based on the source IP address and sends it through the originating interface, which in our example above, is eth0.20.

Note For the Cisco AXP network configuration, the destination interface to which you send the response packet is the same as the incoming interface.

If an application specifies the source IP address when a socket is opened, it will use source-based routing to select the interface to send traffic.

Access Control List

Configuring an access control list (ACL) on the Cisco AXP platform is similar to configuring an ACL on Cisco IOS software.

Packet filtering helps control packet movement through the network by helping to limit network traffic and restrict network use by certain users or devices. Use ACLs to permit or deny packets from crossing specified interfaces.

Using the ip access-list standard command enables standard ACL configuration mode (config-std-nacl). You can then configure the permit command in ACL sub-mode (config-std-nacl) to set up the standard IP access list.

Note In Cisco AXP 1.0.1, you can specify only one IP address in the access control list.

acl-name—Access list to which all commands entered from ACL configuration mode apply, using an alphanumeric string of up to 30 characters, beginning with a letter.

acl-num— Access list to which all commands entered from access list configuration mode apply, using a numeric identifier. For standard access lists, the valid range is 1 to 99.

Step 3

[line-num] permit {source-ip [wildcard]| hostsource-ip|any}[log]

se-Module (confg-std-nacl)> permit 155.168.10.0 any

Adds a line to a standard access-list that specifies the type of packets to be permitted for further processing.

The permit command is used in standard ACL configuration mode (config-std-nacl).

line-num— Entry at a specific line number in the access list.

permit—Allows packets that match the specified conditions to be processed.

source-ip—Source IP address. Number of the network or host from which the packet is being sent, specified as a 32-bit quantity in 4-part dotted-decimal format (for example, 0.0.0.0).

wildcard—(Optional) Portions of the preceding IP address to match, expressed using 4-digit, dotted-decimal notation. Bits to match are identified by a digital value of 0; bits to ignore are identified by a 1.

For standard IP ACLs, the wildcard parameter of the ip access-list command is always optional. If the host keyword is specified for a standard IP ACL, then the wildcard parameter is not allowed.

host— Matches the next IP address.

any—Matches any IP address.

log—(Optional) Sends a logging message to the console about the packet matching the entry.

The message includes the access list number, whether the packet was permitted or denied, the source address, and the number of packets.

The message is generated for the first packet that matches the entry, and then repeats at 5-minute intervals, including the number of packets permitted or denied in the previous 5-minute interval.

Verifying Access Control Lists

To use the show ip access-list command in Cisco AXP EXEC mode to view the access control lists configured on the platform, perform the following step.

SUMMARY STEPS

1. show ip access-list [<1-99> | <name> ][ interfaceintf ] [details]

DETAILED STEPS

Command or Action

Purpose

Step 1

show ip access-list [<1-99>|<name> ][ interface <intf>][details]

SE-Module>show ip access-list

List the rule set of an access-list specified by number or name. It also lists the access-list associated with a specific interface.

If a name or number of the interface is not entered, the command lists the entire rule-set of all the access lists configured in the system.

1-99—Access list number

name—Access list name

intf—Interface name.

details—The raw iptable format of display will be used to display the chain created by the ACL list.

Configuring Source Based Routing

Route Map Policy

Configure only one route-map set because only one set is applied under the ip local policy command. Do not apply the second set to the CLI even if the second set is not used.

Example:

set 1:

route-map APPCUSX 10

match ip address 10

set route table 10

exit

route-map APPCUSX 20

match ip address 20

set route table 20

exit

set 2:<-------Do not apply

route-map APPCUSY 10

match ip address 10

set route table 10

exit

route-map APPCUSY 20

match ip address 20

set route table 20

exit

Note In the steps below, the command interface Integrated-Service-Engine 1/0.1 is not permitted if the AIM service module is being used. Creation of a subinterface on the AIM service module interface is not supported.

SUMMARY STEPS

1. Configure the following Cisco IOS commands on the router. Configuration steps here include configuring the routing/forwarding (VRF) tables. For more information on VRF-Lite, refer to Configuring VRF-Lite.

acl-name—Access list to which all commands entered from ACL configuration mode apply. using an alphanumeric string of up to 30 characters, beginning with a letter.

acl-num— Access list to which all commands entered from access list configuration mode apply, using a numeric identifier. For standard access lists, the valid range is1 to 99.

You can set further options under standard ACL configuration mode (config-std-nacl) as shown in the remaining steps.

[line-num] permit {source-ip [wildcard]| hostsource-ip|any}[log]

se-Module(config-std-nacl)>permit

Configured in access-list configuration mode.

Adds a line to a standard access-list that specifies the type of packets to be permitted for further processing.

Use the permit command in standard ACL configuration mode (config-std-nacl).

line-num (optional)— Entry at a specific line number in the access list.

permit—Allows packets that match the specified conditions to be processed.

source-ip—Source IP address. The number of the network or host from which the packet is being sent, specified as a 32-bit quantity in 4-part dotted-decimal format (for example, 0.0.0.0).

wildcard—(Optional) Portions of the preceding IP address to match, expressed using 4-digit, dotted-decimal notation. Bits to match are identified by a digital value of 0; bits to ignore are identified by a 1.

Note For standard IP ACLs, the wildcard parameter of the ip access-list command is always optional. If the host keyword is specified for a standard IP ACL, then the wildcard parameter is not allowed.

host— Matches the following IP address.

any—Matches any IP address.

log—(Optional) Sends a logging message to the console about the packet matching the entry.

The message includes the access list number, whether the packet was permitted or denied, the source address, and the number of packets.

The message is generated for the first packet that matches the entry, and then repeats at 5-minute intervals, including the number of packets permitted or denied in the previous 5-minute interval.

exit

Exits access list configuration mode.

route-mapmap-tagnumber

se-Module(config t)> route-map

Enters route map configuration mode. The route map is used to match source filtering with a specific routing table.

map-tag—Select a name for the route map.

number—Select a route map number from 1 to 100.

match ip address {acl-num|acl-name }

se-Module(config-route-map)>match

Matches the IP address for the route map using either the number or the name of the access control list.

acl-num—Access control list number.

acl-name—Name of the access control list.

set route tabletable-num

se-Module(config-route-map)>set

Sets the route table.

table-num— Same table number as in the ip route table command.

exit

Exits route-map subcommand mode.

ip local policy route-mapmap-tag

se-Module(config)> ip local policy route-map

Identifies a route map to use for policy routing.

map-tag—Name must match the map-tag in the route-map command.

ip route tabletable-numdest-prefixnet-maskdefault-gw

se-Module(config)> ip route table

Sets the route table for a specific destination prefix and default gateway.

table-num—Same table number as in the ip route table command.

dest-prefix—Destination prefix

net-mask—Network mask

default-gw—Default gateway

ip route table table-numdest-prefixnet-maskblackhole

se-Module(config)> ip route table

able-num—Same table number as in the ip route table command.

dest-prefix—Destination prefix

net-mask—Network mask

default-gw—Default gateway

blackhole—Sets a blackhole route for dropping packets.

exit

Exits global configuration mode.

Source Based Routing Example

Source Based IP Routing

interface eth0.100

ip route table 10 <-- sets up the connected route for table 10

ip address 209.165.201.1 255.255.255.224

exit

Interface eth0.200

ip route table 20

ip address 11.11.10.2 255.255.255.0

exit

ip access-list standard 100

permit 10.7.8.9 <-- Source address that will be used for source based routing

Remote serial device configuration on the Cisco AXP service module is dependent on the Cisco AXP vserial device add-on package which is of the type:axp-vserial.<platform>.<version>.pkg.

This add-on package enables an application running on the service module to access external Cisco IOS serial devices connected to the serial port of a Cisco IOS router. For example, applications can support peripherals that connect to serial ports such as GPS locators.

Note A maximum of 16 serial devices, including the AUX line, are supported by the virtual serial device package.

Cisco AXP currently supports the following asynchronous interfaces:

•HWIC-4T

•HWIC-4A/S

•HWIC-8A/S-232

•HWIC-8A

•HWIC-16A

Table 4 Cisco AXP Asynchronous Support

Specification

HWIC-4T

HWIC-4A/S

HWIC-8A/S-232

HWIC-8A

HWIC-16A

Asynchronous support

Y

Y

Y

Y

Y

Asynchronous maximum speed (per port)

230.4 Kbps

230.4 Kbps

230.4 Kbps

230.4 Kbps

230.4 Kbps

Bisync support

N

N

N

N

N

Serial protocols

EIA-232

EIA-232

EIA-232

EIA-232

EIA-232

Lead manipulation

Y

Y

Y

Y

Y

Network clock synchronization

Y

Y

Y

N

N

The Cisco IOS router's auxiliary serial ports are virtualized and appear in the Cisco AXP OS as local devices. External devices connected to the Cisco IOS router appear as standard local devices such as "/dev/tty1" or "/dev/tty2" to Linux applications hosted on application service modules.

Third party applications can therefore control external peripherals attached to the router's auxiliary serial port without special knowledge of the location of the devices. Applications can open/close/read/write to the peripherals using standard Linux System calls such as: open("/dev/vtty1"), and read( ).

When the virtual serial device opens, a reverse telnet session is established, connecting to the Cisco IOS software host line interfaces. All serial data transfer is carried through this reverse telnet session.

Note Reverse telnet works only with line interfaces, and with serial interfaces that are configured in async mode. Reverse telnet does not work if serial interfaces are configured in synchronous mode.

Linux applications use the virtual device driver to control and receive signal state notifications on all async RS232 leads. A fixed TCP port is assigned to each of the TTY and AUX lines, and to the serial interfaces in ASYNC mode, when reverse telnet is implemented in Cisco IOS software.

The following are the vserial APIs available on AXP side:

•show device serial —Lists all the serial devices accessible from AXP

•bind serialname —Available inside the application's context and is used to bind a particular serial device to an application.

In Cisco AXP 1.1 release, vserial supports only the following subset of the twelve options specified in RFC 2217 protocol:

The port-index and the TCP port for various interfaces are pre-defined in Cisco IOS software, and are shown in Table 5.

Table 5 Cisco IOS Software Line Numbers and Port Values

Interface Name

Port Index

TCP Port

Console

0

Cannot be used.

tty1

1

6001

tty2

2

6002

...

...

...

ttyn

n

600n

AUX

n+1

600(n+1)

vtty1

n+2

600(n+2)

...

...

...

Serial interface in ASYNC mode

Platform dependent

Platform dependent

PREREQUISITE TASKS

•The vserial add-on package (for example, axp-vserial.aim.1.0.5.pkg and axp-vserial.aim.1.0.5.prt1) must be first installed, followed by an installation of the third party application before commencing with the following configuration. For a list of software packages for the latest Cisco AXP 1.0.x release, refer to the Cisco AXP Release Notes.

Specifies BEEP as the transport protocol for NETCONF and configures a peer as the BEEP listener.

b.

Configure the serial interface in async mode:

config t

Enters configuration mode

interface serialslot/subslot/port

Defines the interface serial parameters.

physical-layer async

Configures the interface for async communication.

no ip address

No ip address is set.

lineline-num

Configures the console terminal line and enters line configuration sub-mode.

line-num— Line number

no exec

Turns off the EXEC process for the specified line in the line command.

transport inputtelnet

Defines the protocols for connection to a specific line of the router.

telnet—Specifies all types of incoming TCP/IP connections

speedbaud-rate

Sets the transmit and receive speeds

exit

Exits line configuration sub-mode.

exit

Exits configuration mode.

c.

Configure lines for reverse telnet and asynchronous
interface with stop bits and parity:

interface asyncslot/subslot/port

Defines the interface asynchronous parameters.

no ip address

IP address is not set

encapsulation slip

Configures slip encapsulation

line line-num

Configures the console terminal line and enters line configuration sub-mode.

line-num— Line number

no exec

Turns off the EXEC process for the specified line in the line command.

transport preferred none

Specifies the transport protocol that the Cisco IOS software uses if the user does not specify one when initiating a connection.

none— Prevents any protocol selection on the line. The system normally assumes that any unrecognized command is a hostname. If the protocol is set to none, the system no longer makes that assumption. No connection is attempted if the command is not recognized.

transport input all

Defines the protocols for connection to a specific line of the router.

all—Selects all protocols.

transport outputall

Defines the protocols for connection to a specific line of the router.

all—Selects all protocols.

stopbitsnumber

Sets the number of stop bits transmitted per byte.

number— Number of stop bits.

parityvalue

Sets terminal parity

speedbaud-rate

Sets the transmit and receive speeds

exit

Exits line configuration sub-mode.

exit

Exits configuration mode.

Step 2

On the Cisco AXP Service Module:

a.

Configure NETCONF over BEEP

netconf max-sessionssession-number

Specifies the maximum number of concurrent NETCONF sessions allowed.

netconf beep initiatorrouter-IP-addressport-number

Specifies BEEP as the transport protocol for NETCONF sessions and configures a peer as the BEEP initiator.

b.

Bind the interface and serial devices:

config t

Enters configuration mode.

app-service serialapp

Enters application service mode.

serialapp—Serial device application name inside the third party application.

bind interface network-interface-name

Attaches the networking device to or from the virtual environment.

bind serialdevice-id [device-id-on-hosting
environment]

Example:

bind serial vtty000 modem

Binds the serial device, which is connected to the Cisco IOS software side, inside the virtual environment.

If the bind command is successful a device node /dev/modem is created in the application's virtual instance and the user can access the device as any other regular device

device-id— Device ID of the serial device connected to the Cisco IOS software side. Use the show device serial command to view device ID.

device-id-on-hosting-environment—(Optional) Designates a name that is different from the device ID (device-id) inside the hosting environment.

end

Exits application service mode.

app-serviceserialapp

Enters application service mode.

serialapp— Serial device application name inside the third party application.

reset

Resets the application service environment.

end

Exits application service mode.

Verifying Remote Serial Devices

Use the show line command on the router to obtain the IOS serial device configuration, and then use the show device serial command on the Cisco AXP service module to view all the remote serial devices.

SUMMARY STEPS

1. On the router

show line

2. On the service module

show device serial

3. (Optional) show processes | include beep

DETAILED STEPS

Command or Action

Purpose

Step 1

show line

Esample:

router#show line

Displays the Cisco IOS serial device configuration. The line numbers displayed in the output are the same as the port index.

Step 2

show device serial

Example:

se-Module> show device serial

Displays all the remote serial devices detected by the service module.

Step 3

(Optional) show processes | include beep

(Optional) Displays processes running with NETCONF over BEEP. Use this command if the show device serial command in step 2 does not show any remote serial devices. (Alternative command: show processes | include NETCONF).

Verifying Remote Serial Device: Example

router# show line

Tty Line Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int

* 0 0 CTY - - - - - 2 0 0/0 -

1 1 AUX 9600/9600 - - - - - 2 0 0/0 -

0/0/0 2 TTY 9600/9600 - - - - - 0 0 0/0 Se0/0/0

0/0/1 3 TTY 9600/9600 - - - - - 0 0 0/0 Se0/0/1

* 66 66 TTY 9600/9600 - - - - - 2 0 0/0 -

514 514 VTY - - - - 23 0 0 0/0 -

515 515 VTY - - - - 23 0 0 0/0 -

516 516 VTY - - - - 23 0 0 0/0 -

In the show device serial command output shown below, the Line Type, Line No. and Interface Name fields are mapped to the output of the show line command. The Assigned To field is set by the bind command and shows the specific application to which the remote serial device is attached.

If the bind command is successful a device node /dev/modem is created in the
application's virtual instance and the user can access the device as any other regular
device

Configure NETCONF over BEEP

netconf beep initiator 1.100.40.221 1000

netconf max-sessions 16

Packet Analysis

You can use either network analysis monitoring, or router IP traffic (RITE) features for monitoring packets on the Cisco AXP platform. Both features are very similar to the features available on Cisco IOS software platforms.

Use packet monitoring when there is only one application service module installed in the router.

Depending on your application, and the traffic analysis required for that application, these suggestions may help you choose appropriate features for your application:

Note Both features can be configured at the same time, however, we do not recommend simultaneous feature configuration. Each feature performs its own duplication, resulting in receipt of duplicated packets if both features are configured at the same time.

Creates or edits an IP traffic export profile, enables the profile on an ingress interface, and enters RITE configuration mode.

Step 3

interface Integrated-Service-Engine slot /0

Example:

Router(config-rite)# interface Integrated-Service-Engine 1/0

Enters interface configuration mode for the slot and port where the service module resides.

•slot—Specifies the service module slot.

Step 4

bidirectional

Example:

Router(config-rite)# bidirectional

Exports incoming and outgoing IP traffic on the monitored interface.

Note If this command is not enabled, only incoming traffic is exported.

Step 5

mac-addressH.H.H

Example:

Router(config-rite)# mac-address

Specifies the 48-bit address of the destination host that is receiving the exported traffic.

Since the service module is set to route packets by default, configuring a valid MAC address causes the routing stack of the service module to route the traffic, resulting in duplicated packets being routed.

To avoid this scenario, consider configuring an invalid MAC address which is different from the MAC address of the service module.

Since the service module configuration is in promiscuous mode, an invalid MAC address will also work, allowing traffic to reach the service module without being routed.

Configures the IP address and network mask for the specified network interface.

Step 5

end

Exits interface configuration mode.

Step 6

app-serviceapplication-name

Enters application service mode.

Step 7

log server addresshostname

Enables remote logging and configures the remote logging server.

Application syslog messages are sent to the specified log server.

The hostname can be an IP address or hostname.

When you enter an invalid IP address such as 0.0.0.0, the following error message appears:

Error Message 0.0.0.0 is an invalid Host IP
address

Configuring System Log Levels

SUMMARY STEPS

1. configure terminal

2. app-serviceapplication-name

3. log levellevels

DETAILED STEPS

Command or Action

Purpose

Step 1

configure terminal

Enters global configuration mode.

Step 2

app-serviceapplication-name

Enters application service mode.

Step 3

log levellevels

Example:

SE-Module(config-app-service)> log level info

Configures the system log level.

Applicable levels are:

info— Events with LOG_INFO and higher severity are logged, including all messages described in notice.

warn (Default)—Events with LOG_WARNING and higher severity are logged, including all error messages described in err.

err—Events with LOG_ERR and higher severity are logged, including LOG_EMERG, LOG_ALERT, and LOG_CRIT.

notice —Events with LOG_NOTICE and higher severity are logged, including all messages described in warn.

debug—Events with LOG_DEBUG and higher severity are logged, including all messages described in info.

Configuring Resource Utilization Limits

Cisco AXP 1.1 provides the flexible resource allocation feature as part of the resource management system. It provides developers the flexibility to package an application without completely determining the hardware's capability to support that application.

Use the limit memory utilization command to set memory limits. To set CPU and disk limits, use the limit cpu utilization andlimit disk utilization commands.

Flexible Resource Allocation

Flexible resource allocation grants extra CPU, memory and disk resources to an application if these resources are available, and allows these non-allocated resources to be shared between all virtual instances.

Flexible resource allocation is disabled by default. If it is not enabled, an application is installed only if resource limits are set before packaging the application.

Users can manually override any resource limits on a given application by using the resource limits CLI. If you override resource limits for an application, then flexible resource allocation cannot be applied to that application.

Flexible resource allocation occurs after these events:

•Installing an add-on package

•Upgrading an existing package

•Uninstalling an installed package

•Changing resource limits using the CLI

Resource Limits Exceeded after Downgrade

The following scenario may occur after downgrading an application on Cisco AXP.

If the current software on the service module is App V2 with Cisco AXP host OS 1.1.1, and a downgrade is performed to a lower version of Cisco AXP host OS (for example, 1.0.6) using App V1, the files for App V2 may still be present on the application service module.

The presence of two versions of the application may cause resource limits to be exceeded. Error messages may be displayed when trying to run App V1 (referenced as APP1 in the error message) on Cisco AXP host OS (1.0.6):

Verifying Resource Utilization Limits

SSH Access to a Virtual Instance

Secure Shell (SSH) Protocol tunneling is a secure and effective solution for network users and administrators. SSH tunneling, also known as SSH port forwarding, is the process of forwarding selected TCP ports through an authenticated and encrypted tunnel.

The tunnel_root SSH user allows full access to the guest OS shell; the tunnel_user SSH user allows only controlled access.

SSH access may be selected through tunnel_root and tunnel_user if an application depends on an axp-app-dev package, such as axp-app-dev.aim.1.0.5.pkg.

Only tunnel_user can be selected if an application depends on an axp-app-ssh package, such as axp-ssh-4.6p1-k9.nme.1.0.5.pkg.

Synchronizing Files

Cisco AXP provides developers with a data synchronization feature that allows them to synchronize files from a virtual instance to their workstation. The sync file url command synchronizes data from the virtual instance to the workstation using the rsync utility. The synchronization feature uses the rsync utility to exclude hard-linked files from the synchronization process.

Hard-linked files from the Guest-OS and other add-on files are excluded from synchronization since they are not packaged in an application. If an application requires a hard-linked file on the Cisco AXP service module to be overwritten with a file from a developer's workstation, it is necessary to first log into the Linux session in the virtual instance and remove the hard-linked file's protection.

If a file (or its directory) is deleted from one location and is used as the source of a synchronization operation, the file (or its directory) on the other location will not be automatically deleted. It must be manually deleted.

For example, if /work/helloworld-app-content/etc/mtab is deleted from the workstation repository and sync file url command is invoked with the in keyword, the file on the Cisco AXP service module will not be automatically deleted.

Files that are not protected (not hard-linked from the Guest-OS or add-on files), will be synchronized out of the Cisco AXP service module for that virtual instance. These files include:

•All files added by the developer

•Temporary files used by run-time Linux

•Basic directory structures

The synchronization feature depends on:

•Guest-OS and add-on files hard-linked (UNIX file system link) in the virtual instance.

•rsync utility

Prerequisites

The following tasks must be performed before synchronizing files.

Workstation

On the workstation, the rsync utility is installed by default with the recommended Redhat platform. Cisco AXP invokes rsync remotely using SSH.

For the rsync utility to be initiated from the service module, the following tasks must be performed:

1. sshd must be running on the workstation

2. The workstation must be connected through the network from the router.

3. The developer must have a valid account on the workstation.

4. A directory must be available to contain the synchronization process content.

5. The ~/.ssh folder must have read, write and executable permissions for the owner.

Application

The application (empty application for starting developing) must be dependent on the application debug package to provide access to the Linux shell and rsync utility.

Since rsync requires network connectivity, the application must be configured to bind an interface.

•Configure SSH authentication keys to allow rsync session initiations without having to provide a password for each session. This configuration is required only once.

SUMMARY STEPS

1. app-service application-name

2. sync file url rsync:host_url direction [in|out] username username

3. exit

DETAILED STEPS

Command or Action

Purpose

Step 1

app-service application-name

Enters application service mode.

Step 2

sync file url rsync:host_url direction [in|out]
username username

Wraps the rsync command. Before invoking the rsync utility, the command first identifies the files that can or should be synchronized.

This identification process avoids synchronizing files that were hard-linked in the virtual instance, such as files from the Guest OS or other add-on files.

rsync— Defines the rsync protocol

host_url— Host URL

direction—Direction of synchronizing the files:

in—Content from the workstation is used as the master file.

out—Content from the service module is used as the master file.

username—Username used for authentication to the remote host (developer's workstation).

Step 3

exit

Exits application service mode.

Synchronization Example

This example assumes that the prerequisite tasks have been performed and the application is installed and configured on the Cisco AXP service module.

Setup

•Workstation (rsync repository) address: 192.168.1.4

•Username used by the developer on the workstation: john

•Empty application name: helloworld

•Cisco ISR prompt:

Router>

•Cisco AXP service module prompt:

appre>

•Workstation's folder to be used as a repository: /work/helloworld-app-content

Configuring SSH Authentication Keys

Configure the SSH authentication keys to establish trust between the service module and the workstation before using the sync file url command.

SUMMARY STEPS

1. Access a Linux shell session on the service module's application

2. Generate a key for the service module

3. Load the service module's public key to the workstation

4. Verify setup

Step 1 Setup a Linux session on the service module. Use the linux shell and connect console commands to access the guest OS shell. You can obtain console access for your application by using a debug package as a dependency, or by using a postinstall script.

a. To enable the linux shell command, first obtain console access using a debug package as a dependency. Refer to the section, Obtaining Console Access for the Application in the Cisco Application eXtension Platform Developer Guide.

b. To enable the connect console command, first obtain console access using the postinstall script. Refer to the section, Obtaining Console Access for the Application in the Cisco Application eXtension Platform Developer Guide.

appre> app-service helloworld

appre>(exec-helloworld)>

appre>(exec-helloworld)> linux shell

bash-2.05b#

Step 2 Generate keys.

Use ssh-keygen to generate keys for the network-module.

Do not provide a passphrase. Save the generated keys under /root/.ssh/id_rsa since ssh will be looking for it.

Step 3 Upload the service module's public key to the workstation to ensure that the service module's public key is known by the workstation. A simple way to upload the public key is to use the scp utility.

Note john is the username or account on the workstation. We will use the same username to invoke the rsync command.

Step 4 Verify setup.

We can verify the setup of the authentication key by launching a simple SSH session from the service module to the workstation.

bash-2.05b# ssh john@192.168.1.4

You should not be prompted for a password for this command and should get a SSH session right away. If you do not initiate a SSH session immediately verify that:

•The right key has been uploaded. The key must be uploaded on the same machine to which you are initiating ssh during the verification step.

•The username is the same.

•The scp operation destination does not contain any typographical errors.

Step 5 Use the sync file url command

Perform data synchronization between the service module application files and the workstation repository. The first time you synchronize, it is recommended that you synchronize out (service module to the workstation) so that the base directory layout is exported.

Synchronizing out for the first time also makes it easier to add files to the structure.

In this example, we invoke the rsync command from the application context from the CLI prompt:

Using this command exports the data to the workstation 192.168.1.4 and places all the data of the application, which resides on the service module, under the workstation's directory /work/helloworld-app-content.

Theusername john is used as credential for the connection.

The exported data must contain the following:

•Basic directory structure

•Temp files that were used in the virtual instance such has /tmp/*, /var/log/*, /var/lock/*

•Original files that were originally packaged in the application

At this point, files can be added and modified in the workstation repository and be synchronized back in, using the same command but using in instead of out as direction.

CLI Plug-in Invocation

Developers must implement APIs using the signatures provided in of the Cisco AXP Developer Guide and compile the APIs into application C libraries or Java classes. The CLI plug-in distribution service invokes these APIs when a user enters a command referring to one of these action classes.

EXEC Mode

Invoke an EXEC CLI plug-in as follows:

SUMMARY STEPS

1. app-service application-name

2. Enter the CLI plug-in as defined by the third party application.

3. exit

DETAILED STEPS

Command or Action

Purpose

Step 1

app-service application-name

Example:

SE-Module>(exec-helloworld) disconnect users 20

•Invokes a plug-in command in EXEC mode.

•application-name— Application name.

•Enter a query (?) to autogenerate a list of application names.

•After entering the app-service sub-mode, enter the CLI plug-in defined by the third party application.

Cisco IOS Service API Configuration

Common service APIs (supported in Bash, C, C++, Java, Perl, and Python) are as follows:

•Generic EXEC commands:

This API allows an application to specify an EXEC command and return a string of output. The third party application must parse the output to retrieve the desired data.

The supported EXEC CLIs are as follows:

–show commands and/or their output modifiers.

–write memory to save changes to NVRAM.

–copy running-config startup-config to save changes to a startup configuration.

•Generic configuration commands:

The service API allows an application to specify configuration commands consisting of a string of command(s) or a file path that contains commands separated with a delimiter such as a semicolon ;

If a connection attempt fails to access a Cisco IOS NETCONF agent, the timeout value is set to 120 seconds. A FAIL code (1) is returned with an error message:

Fail to connect to IOS

It is the calling program's responsibility to allocate or free up the memory required to accommodate the response from Cisco IOS software for C programs. For Java and other languages, the default size of the response is 2048 bytes. A reply less than 2048 bytes is returned and embedded in the response string.

A reply larger than the size of the buffer allocated, or larger than the default value, the reply is placed in a file. A FILE code (2) is returned, and the file path and name are embedded in the response. The calling program can only retrieve the Cisco IOS software reply from the file.

Note NETCONF over BEEP must be enabled on the router and the Cisco AXP service module for this feature to work.

Specifies BEEP as the transport protocol for NETCONF and configures a peer as the BEEP listener.

Configure the following on the Cisco AXP service module:

Step 1

netconf beep initiatorrouter-IP-addressport-number

Specifies BEEP as the transport protocol for NETCONF sessions and configures a peer as the BEEP initiator.

Step 2

netconf max-sessionsnum

Specifies the maximum number of concurrent NETCONF sessions.

num—Maximum number of sessions.

Verifying and Clearing Cisco IOS API Records

Use the show history iosapi and clear history iosapi commands to view EXEC and configuration command activities, and to clear specific records. Use the show log name messages.log command in Cisco AXP EXEC mode to view the audit history.

To enable these commands, first download and install the iosapi package, axp-iosapi.<platform>.<version>.pkg

Note The show history iosapi command helps to track command changes. You can view up to a hundred records where each record shows a configuration command change or an EXEC command change for a single virtual instance. Each virtual instance records up to seventy configuration command changes and thirty EXEC command changes.

SUMMARY STEPS

1. app-service application-name

2. show history iosapi [num ]

3. show history iosapi [exec | config ] [num ]

4. clear history iosapi [num ]

5. clear history iosapi [exec | config ] [num]

6. exit

7. show log name messages.log | include "iosapi audit"

DETAILED STEPS

Command or Action

Purpose

Step 1

app-service application-name

Enters application service EXEC mode.

Step 2

show history iosapi [num]

Displays up to the last hundred records for configuration and EXEC modes.

num—Number of records to be displayed.

Step 3

show history iosapi [exec|config ][num ]

Displays up to the last hundred records for the specified mode.

exec—EXEC mode

config—Configuration mode

num—Number of records to be displayed.

Step 4

clear history iosapi [num]

Clears the number of specified records for configuration and EXEC modes.

num—Number of records to be displayed.

Step 5

clear history iosapi [exec|config][num]

Clears the number of specified records for the specific mode.

exec—EXEC mode

config—Configuration mode

num—Number of records to be cleared.

Step 6

exit

Exits application service EXEC mode.

Step 7

show log name messages.log | include "iosapi
audit"

SE-Module> show log name messages.log|incude
"iosapi audit"

Displays audit history in Cisco AXP EXEC mode.

Cisco IOS Event Registration

To register an event using a third party application on Cisco AXP, either register an event using a configuration file or register an event using the CLI on the Cisco AXP service module. Then verify the events are registered. For further information, see the following sections:

Registering an Event using the Event Configuration File

We recommend this registration method. You (the developer) register an event in an event configuration file in XML format. You then package the configuration file with the application and install the application package on the service module. See "Embedded Event Manager API" in the Cisco AXP Developer Guide.

Registering an Event using the Cisco AXP Service Module

To register an event on the Cisco AXP service module using the CLI, perform the following steps.

SUMMARY STEPS

1. configureterminal

2. app-serviceapplication-name

3. eventevent-nameregister|unregisterevent-type

4. end

5. copy running-config startup-config

6. app-serviceapplication-name

7. reset

DETAILED STEPS

Command or Action

Purpose

Step 1

configureterminal

Enters configuration mode.

Step 2

app-service application-name

Enters application service config mode.

Step 3

eventevent-nameregister|unregisterevent-type

Registers or unregisters an event and specifies the type of event. Example types: cli, timer, or interface. (For more event types, see "Embedded Event Manager API" in the Cisco AXP Developer Guide.)

Step 4

end

Exits config mode.

Step 5

copy running-config startup-config

Backs up the current configuration.

Step 6

app-service application-name

Enters app service config mode.

Step 7

reset

Resets the vserver for the application, so that the changes can take effect.

Verifying Registered Events

To verify the events registered for your application, perform the following step.

SUMMARY STEPS

1. show run

DETAILED STEPS

Command or Action

Purpose

Step 1

show run

Displays running configuration including registered events.

Example:

show run

app-service eemapi_test

bind interface eth0

event <event name> register <event type>
<parameter>

Each line beginning with "event" shows an <event name> and <event type> that should correspond to one of the expected registered events for your application. If any events are missing, register the missing events using one of the two methods for "Cisco IOS Event Registration" section.

Using CLI to Trigger a Syslog Event

To manually trigger a syslog event by logging onto an interface, perform the following steps on the router.

1. configure terminal

Enters configuration mode.

2. logging bufferedbuffer-size

3. interface interface-name

Selects the type of interface to be recorded in the syslog. This is dependent upon having first set up an event-type of "syslog" with a pattern to be matched. For example, attribute pattern = "gigabitEthernet 0/1".

4. shutdown

Shuts down the interface. Sends event information to syslog.

5. no shutdown

Starts the interface. Sends event information to syslog.

6. exit

Exits configuration mode.

Troubleshooting a Cisco EEM API Configuration Event

To track ios_config events on the router, perform the following step.

•debug beep session

To track ios_config events on the Cisco AXP service module, perform the following step.

•trace eemapi all

To check the var/log/messages.log file perform the following step.

•show log name messages.log

In the following example, the ending of the command "containing EEM paged" causes the output to be filtered.

Modifying an Event

Use the event command to enable or disable the parameter of a registered event. Also use the event command to add, delete or modify an event. An event is not updated until a virtual instance reset command is issued.

SUMMARY STEPS

1. configure terminal

2. app-serviceapplication name

3. [no] eventevent-name {register | unregister} event-typeparameter

4. exit

DETAILED STEPS

Command or Action

Purpose

Step 1

configure terminal

Enters configuration mode.

Step 2

app-serviceapplication name

Enters application service mode.

Step 3

[no] eventevent-name {register | unregister}
event-typeparameter

Adds, edits, or deletes an event.

register—Enables the event

unregister—Disables the event

Example 1:

no event myevent

Deletes the event myevent.

Example 2:

event mysecondevent register cli
parameter1

Adds the event mysecondevent (if it does not already exist), and enables parameter1.

Example 3:

event mysecondevent unregister cli
parameter

Disables parameter1 from the event mysecondevent.

Step 4

exit

Exits application service mode.

Application Status Monitor

Cisco AXP allows third party applications to plug-in their status monitoring and allows recovery from a malfunctioned state.

An application must provide one or more watchdog scripts or executable files bundled in their package to use the Cisco AXP application monitoring feature. The number of scripts or executables is dependent on the application, resulting in a unique way of determining the status of the application. For example, it can be based on Process Identifier (PID), or a response to an application ping. Cisco AXP supports Shell scripts and C language executables for application status monitoring.

For more information on watchdog scripts and executables, refer to the Cisco AXP Developer Guide.

The application status monitor has a heartbeat of 5 seconds, which is the minimum interval used for monitoring. For example, if the monitor interval is set at 12, monitoring of each virtual instance takes place every 12 heartbeat intervals, which is every one minute. You can configure the monitoring interval for a virtual instance through the status-monitor monitor interval command.

The scripts or executables return a status code where zero indicates that the application is healthy and alive. A non-zero status code indicates that the application is not functional. When a watchdog script or executable returns a non-zero status code, relevant information such as the name of the watchdog script, return status, and time of failure is logged.

A recovery counter counts the number of times the failure takes place, and acts like a delay mechanism for further action. A recovery count of three means that the application monitor has run for three iterations and is receiving either a non-zero return status, or the watchdog script has been running for over 3 monitoring intervals and is not returning a value.

You can use the status-monitoring monitor interval command for configuring the recovery threshold that decides on the number of recovery counters before taking the next action. When the recovery threshold is reached, the virtual instance restarts and the application monitor continues to run, repeating the monitoring cycle. A virtual instance can restart any number of times.

Third party developers can also provide default configuration parameters through a configuration file packaged together with their party application.

Bundles all the syslog server log files into a gzip file and copy it to a remote URL.

destination-filename.gz—gzip filename

ftp/http url—Destination URL

Step 6

copy syslog-server log namelog-nameurlftp/http url

Copies the specified syslog server log file. Wildcard * may be used to copy more than one log file at a time.

Step 7

exit

Exits system EXEC mode.

Viewing the Application Status Monitor

SUMMARY STEPS

1. app-service application-name

2. show status-monitor

3. exit

DETAILED STEPS

Command or Action

Purpose

Step 1

app-service application-name

Enters application service mode.

Step 2

show status-monitor

Displays parameters of the status monitor.

The monitor status shown in the example can have one of the following values:

--- : Monitor has not been turned ON.

PASSED: Monitoring reports successful execution of watchdog scripts.

RECOVERY: Monitoring reports a watchdog failure, or the watchdog is taking longer than the monitor interval to return a value. The virtual instance restarts if the recovery threshold period is exceeded.

Example:

Application: helloworld

Monitor status: PASSED

Monitor in progress: Yes

Last executed watchdog: W00template.sh

Last executed date: Wed Sep 5 14:09:58 PDT 2007

Last failed watchdog: ---

Last failed return code: -

Last failed date: ---

Last restarted date: ---

Recovery threshold: 4

Monitor interval: 3

Step 3

exit

Exits application service mode.

Viewing the Application State

SUMMARY STEPS

1. app-service application-name

2. show state

DETAILED STEPS

Command or Action

Purpose

Step 1

app-service application-name

Enters application service mode.

Step 2

show state

Displays the state and health of the specified application as:

State—Online, Offline, Pending-online, Pending-offline.

Health—Alive or Down.

Viewing Processes

SUMMARY STEPS

1. app-service application-name

2. show process

3. show process running

4. show process all

5. show process pid process-id

DETAILED STEPS

Command or Action

Purpose

Step 1

app-service application-name

Enters application service mode.

Step 2

show process

Shows all processes running in the application environment sorted by process ID in ascending order.

Step 3

show process running

Shows all running processes in the application environment sorted by CPU usage in descending order.

Step 4

show process all

Shows all processes running in the application environment with a summary of CPU and memory tasks in the application environment.

Step 5

show process pidprocess-id

Shows the process, specified by the process ID, running in the application environment.

Verifying Swap Space Support

Use the show swap usage command in Application Service EXEC mode to view swap space usage of each application. The show tech-support command also displays the available swap partition on the blade.

SUMMARY STEPS

1. app-service application-name

2. Show tech-support

3. show swap usage

4. exit

DETAILED STEPS

Command or Action

Purpose

Step 1

app-service application-name

Enters application service EXEC mode.

Step 2

show tech-support

Dumps information on the terminal provided by the third party application.

Executes the /bin/techsupport binary or script file to display application specific information if provided by the third party application.

Displays the available swap partition on the blade and shows swap turned on or off.

Example: Swap turned on

swap is turned ON

Filename Type Size Used Priority

/dev/sda3 partition 1959920 0 -2

Example: Swap is turned off.

Swap is turned off.

Step 3

show swap usage

Displays swap space usage of each application. This CLI is available inside each application's context.

Step 4

exit

Exits application service EXEC mode.

SSH Server Status

SUMMARY STEPS

1. app-service application-name

2. show ssh-server

DETAILED STEPS

Command or Action

Purpose

Step 1

app-service application-name

Enters application service mode.

Step 2

show ssh-server

Displays the current status of the SSH server.

Viewing Statistics

SUMMARY STEPS

1. app-service application-name

2. show statistics

3. show statistics app

4. end

5. show app-service statistics

DETAILED STEPS

Command or Action

Purpose

Step 1

app-service application-name

Enters application service mode.

Step 2

show statistics

Displays statistics such as CPU utilization and memory for a virtual instance in the application environment.

Example:

CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME

2 3 6.6M 2.5M 0m00s12 0m00s40 3h04m08 Test1

CTX = context number for the virtual instance

PROC = quantity of processes in the context

VSZ = number of pages of virtual memory

RSS = Resident set size limits for memory

userTime = utime User-mode CPU time accumulated

sysTime = ctime Kernel-mode CPU time accumulated

upTime = uptime

Step 3

show statisticsapp

Displays statistics of third party applications integrated into the application environment.

When you use this command, /bin/appstats is executed. The third party application must provide the appstats file, in binary or script format, to plug in for its statistics.

Step 4

end

Exits application service mode.

Step 5

show app-service statistics

Example:

Se-Module> show app-service statistics

(System EXEC mode) Lists all the installed virtual instances and applications, and displays the application instance's memory and processing time information.

Viewing Application Data

SUMMARY STEPS

1. app-service application-name

2. show tech-support

3. show tech-support details

4. exit

In System EXEC mode:

5. show tech-support

DETAILED STEPS

Command or Action

Purpose

Step 1

app-serviceapplication-name

Enters application service mode.

Step 2

show tech-support

Dumps information on the terminal provided by thethird party application.

Displays a summary of diagnostic information of the application environment such as running-config, state, resource limits, and statistics.

Executes the /bin/techsupport binary or script file to display application-specific information if provided by the third party application.

Step 3

show tech-support details

Displays detailed technical support information for the third party application. This command displays output from the show commands applied to the third party application.

Step 4

exit

Exits application service mode.

Step 5

In Cisco AXP EXEC mode:

show tech-support

Displays a summary of diagnostic information.

Viewing Running Configuration

SUMMARY STEPS

1. app-service application-name

2. show running-configuration

3. exit

DETAILED STEPS

Command or Action

Purpose

Step 1

app-serviceapplication-name

Enters application service mode.

Step 2

show running-configuration

Displays running configuration only for the application environment.

Step 3

exit

Exits application service mode.

Verifying Resource Utilization Limits

show resource limits (Cisco AXP EXEC Mode)

Use the show resource limits command in Cisco AXP EXEC mode, to view the new resource limits.

For resource limits that are not currently effective after the last change, the show resource limits command appends an * after each limit value, to indicate that the new values are in a pending state.

If you do not execute the write memory command, the CLI configured value is lost after a reboot.

show resource limits (Cisco AXP application service EXEC mode)

Use the show resource limits command in Cisco AXP application service EXEC mode to view the resource limits in Table 7.

Table 7 show resource limits: Application Name

Application

Application Name

Description

Cpu Package

Value for CPU requirement in Index

Resource limit generated by the packaging tool, specified during packaging.

Memory Package

Value for Memory requirement in MB

Resource limit generated by the packaging tool, specified during packaging.

Disk Package

Value for Disk requirement in MB

Resource limit generated by the packaging tool, specified during packaging.

Cpu Configured

Value for CLI Configured CPU

Resource limit configured through CLI config commands. If no limit is configured through CLI, a dash "-" is displayed.

Memory Configured

Value for CLI Configured Mem

Resource limit configured through CLI config commands. If no limit is configured through CLI, a dash "-" is displayed.

Disk Configured

Value for CLI Configured disk

Resource limit configured through CLI config commands. If no limit is configured through CLI, a dash "-" is displayed.

Cpu Limit

Value for actual CPU limit

Resource limit currently used by the system and vservers. The value may change if resources are rebalanced.

Mem Limit

Value for actual Mem limit

Resource limit currently used by the system and vservers. The value may change if resources are rebalanced.

Disk Limit

Value for actual Disk limit

Resource limit currently used by the system and vservers. The value may change if resources are rebalanced.

Viewing a List of Installed Applications

SUMMARY STEPS

1. show app-service state (system EXEC mode)

2. exit

DETAILED STEPS

Command or Action

Purpose

Step 1

show app-servicestate

Example:

SE-module> show app-service state

Displays a list of the installed applications and their state and health in system EXEC mode.

System EXEC mode is similar to privileged EXEC mode in Cisco IOS software.

State— Online or offline. Indicates if the virtual environment is running.

Health—Alive or down.

Health refers to the status of the internal application.

This status is communicated back to the Cisco AXP environment through an API call by the application monitoring process.

Step 2

exit

Exits application service mode.

Resetting the Examples Application Environment

SUMMARY STEPS

1. app-service application-name

2. reset

DETAILED STEPS

Command or Action

Purpose

Step 1

app-service application-name

Enters application service mode.

Step 2

reset

Resets the specified application environment and places it in the current state.

For example:

•It forces the virtual environment to stop if it is currently in the shutdown state (offline or pending-offline).

•If the virtual environment is currently online, it forces a shutdown and restarts the virtual environment to bring it back online again.

Uninstalling an Application Package

To uninstall an application package, perform the following step.

SUMMARY STEPS

1. software uninstall package name (system EXEC mode)

DETAILED STEPS

Command or Action

Purpose

Step 1

SE-Module> software uninstallpackage name

Uninstalls the previously installed application software package.

The uninstallation will not work if the package does not exist, or if other packages depend on the specified package being uninstalled.

Common Troubleshooting Commands

Tables 3 and 4 show some common router and service module commands.

To view a complete list of available commands, type ? at the promptExample: Router(config-if)# ?.

To view a complete list of command keyword options, type ? at the end of the commandExample: Router# service-module integrated-service-engine?.

Table 8 and Table 9 group commands by the configuration mode in which they are available. If the same command is available in more than one mode, it may act differently in each mode.

To shut down or start up the service module or the Cisco AXP software application that runs on the module, use shutdown and startup commands as needed from Table 8.

Note•Some shutdown commands can potentially disrupt service. If command output for such a command displays a confirmation prompt, confirm by pressing Enter or cancel by typing n and pressing Enter. Alternatively, prevent the prompt from displaying by using the no-confirm keyword.

•Some shutdown commands shut the module or application down and then immediately restart it.

Table 8 Common Shutdown and Startup Commands

Configuration Mode

Command

Purpose

Router#

service-module integrated-service-engine slot/0 reload

Shuts down the service-module operating system gracefully, then restarts it from the bootloader.

Router#

service-module integrated-service-engineslot/0reset

Caution Use this command with caution. It does
not provide an orderly software shutdown and consequently may impact file operations that are in progress.

Resets the hardware on a module. Use only to recover from shutdown or a failed state.

Router#

service-module integrated-service-engineslot/0session

Accesses the specified service engine and begins a service-module configuration session.

Router#

service-module integrated-service-engine slot/0 shutdown

Shuts down the service-module operating system gracefully. Use when removing or replacing a hot-swappable module during online insertion and removal (OIR).

Router#

service-module integrated-service-engineslot/0status

Displays configuration and status information for the service-module hardware and software.

Router(config)#

shutdown

Shuts down the entire system (host router plus service module) gracefully.

SE-Module bootloader>

boot

Starts the bootloader, boothelper, or application.

SE-Module(offline)>

reload

Performs a graceful halt and reboot of a service-module operating system.

SE-Module>

reboot

Shuts down Cisco AXP software without first saving configuration changes, then reboots it from the bootloader.

SE-Module>

reload

Shuts down Cisco AXP software gracefully, then reboots it from the bootloader.

SE-Module>

shutdown

Shuts down the Cisco AXP software application gracefully, then shuts down the module.

Verifying and Troubleshooting System Status

To verify the status of an installation, upgrade, downgrade, or troubleshoot problems, use verification and troubleshooting commands as needed from Table 9.

Note Keyword options for many show commands include provision to display diagnostic output on your screen or pipe it to a file or a URL.

Table 9 Common Verification and Troubleshooting Commands

Configuration Mode

Command

Purpose

Router#

ping

Pings a specified IP address to check network connectivity (does not accept a hostname as destination).

Router#

show arp

Displays the current Address Resolution Protocol (ARP) table.

Router#

show clock

Displays the current date and time.

Router#

show configuration

Displays the current bootloader configuration as entered using the configure command.

Appendix- Port Usage

Table 13 lists the various Cisco AXP ports available to end users for releases 1.1 and 1.1.5, and the programs or services that run on these ports.

Note Refer to the product documentation provided by your third party vendor for any application specific port usage that may apply to your product.

In the table:

•Port usage for some ports varies per release. If the port usage is designated as optional, it implies that the port is used only when the applicable program or service is being run on that port.

Table 13 Cisco AXP Port Usage

Internet Server Port Usage

Port Usage in Cisco AXP Release

Comments

Protocol

Port

Program/Service

1.1

1.1.5

TCP

22

SSH server

Optional

Optional

This port is used only when the Cisco AXP SSH server is configured through the SSH CLI.

Connecting to this port provides access to the Cisco AXP CLI.

TCP+ UDP

53

DNS server

Yes

—

In the Cisco AXP 1.1 release, this port is used by the Cisco AXP DNS server.

This port is available in the Cisco AXP 1.1.5 release. Refer to port 1027.

UDP

69

TFTP server

Optional

Optional

This port is used only when the TFTP server is used by Cisco IOS to support the Cisco EEM service. It is only active on the port when a guest application is installed with a dependency on the Cisco EEM feature.

UDP

123

NTPD

Yes

Yes

This port is used by the standard Cisco AXP NTPD service which is used to synchronize clocks.

UDP

514

Syslog server

Optional

Optional

This port is used only when the syslog server listens on this port. It is enabled or disabled by configuring the syslog server.

TCP+UDP

1027

DNS server

—

Yes

The Cisco AXP DNS server runs on this port in the Cisco AXP 1.1.5 release.

Refer to port 53.

TCP

10333

Cisco EEM service

Optional

Optional

This port is used only when an application that is dependent on the Cisco EEM feature runs the Cisco EEM service.

All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0812R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.