Table Of Contents
Cisco Application eXtension Platform Developer Guide
Cisco Application eXtension Platform Overview
Dedicated Application Resources
Application Packaging Overview
Running Applications on the Guest Operating System
Obtaining Console Access for the Application
Infrastructure Add-on Packages
Development System Requirements
Application Development Overview
CLI Plug-in Utility Tools and APIs
Automatic or Manual Application Startup
Creating a Common Root Directory
Creating a File of Protected Files
Creating a Package Directory for Project
Packaging the Hello World Application: Example
Verifying Your Application is Installed and Running
CLI Plug-in Distribution Service
CLI Plug-in Application Components
Packaging a CLI Plug-in Application
Installing a CLI Plug-in Application
Activating a CLI Plug-in Application
CLI Plug-in Distribution Listener APIs
Interrupting Action Invocation
Simultaneous CLI plug-in Invocation
CLI Plug-in Application: Example
Show Time Application: Example
Troubleshooting Your Application
Bundles Including the Cisco AXP Host OS
Cisco AXP Emulation using VMware
Debugging and Troubleshooting Enhancements
Integrating Log Files into the Host OS
System Performance Status Monitoring
Development Authorization File Modularity
Testing with Older Cisco AXP Images
RITE Traffic Filtering and Sampling
Packet Monitoring and Analysis
Swap Space and Memory Allocation
Displaying Current Resource Limits
Running the RPM File Extractor Tool
RPM File Extractor Tool Arguments
Appendix A: Porting an Application from Fedora Core 6: Examples
Example 1: Simple C++ Application
Example 2: Porting an Existing Application
Identifying Cisco AXP Package Contents
Bundling Libraries in Your Application
Identifying Libraries to Bundle
Library location and LD_LIBRARY_PATH
Appendix B: Commands in Guest OS
Appendix C: Libraries in Guest OS
Cisco Application eXtension Platform Developer Guide
Revised: 11/13/08, OL-14813-01
The Cisco Application eXtension Platform Developer Guide provides information on how to create, package and install applications on the Cisco Application eXtension Platform (Cisco AXP).
Contents
This guide contains the following sections:
•
Cisco Application eXtension Platform Overview
•
•
•
•
•
•
•
•
•
For more information on the following topics, see the Cisco AXP User Guide.
•
•
•
•
•
To obtain the names of recently introduced Cisco AXP features, and the version of Cisco AXP in which they are available, see the Cisco Application eXtension Platform (AXP) Feature History.
Cisco Application eXtension Platform 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 the router's Cisco IOS software or the services can be decoupled and hosted on modular application service modules.
The Cisco ISR allows for blade hardware plug-in modules. These application service modules enhance the functionality, intelligence and flexibility of the router. The Cisco Application eXtension Platform (Cisco AXP) represents the next generation for this set of features.
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 service module, Cisco AXP hosts applications in a separate runtime environment with dedicated resources. In addition, Cisco AXP provides Application Programming Interfaces (APIs) that enable functions such as packet analysis, event notification, and network management to be utilized by hosted applications.
Cisco AXP has facilities and frameworks to host applications, and service APIs for integrating applications into the network.
Cisco AXP provides the following features:
•
These resources (including CPU, memory, disk and network IO) are segmented, which ensures that the application and router features work independently, and without interference.
•
If an application crashes, other applications are not affected and the router continues running normally. This is achieved by having each installed application in its own virtual instance.
•
Native and interpreted applications written in other programming languages can be integrated by the third party application if the third party application uses additional support libraries and interpreters.
•
Only third parties certified by us can install software onto Cisco AXP.
•
•
•
An application can receive the status of a Cisco ISR and take the appropriate action.
•
The Cisco IOS auxiliary serial port can be virtualized and appear in Cisco AXP OS as a local device. The application controls external peripherals attached to the router auxiliary serial port without special knowledge of the where the device is located.
•
The Cisco AXP network interfaces are protected by a firewall for security. Ports can be opened using the "CLI Service API" section.
Figure 1 shows the relationship between applications running on the Cisco AXP host OS of the Application Service Module and Cisco IOS software of the Cisco ISR.
Figure 1 Cisco ISR and Cisco AXP Service Module Interface
Cisco AXP Features
Cisco AXP provides a Linux-based hosting infrastructure. Having a Linux base allows the use of open source software for development. The hosting infrastructure installs and runs applications in separate security contexts using Cisco AXP Virtual Instance Manager. These security contexts all use a common Linux kernel but have separate dedicated resources. Libraries can be independent in each context. The network infrastructure is made more secure by only allowing software that has been developed by Cisco-approved partners to be installed and run on the service module.
The key features of Cisco AXP are:
•
•
•
•
Note
Hosting Infrastructure
Cisco AXP's Linux-based features allow applications to interact with Cisco IOS software. Program interfaces in Cisco AXP enable applications to modify Cisco IOS software configurations, receive notification of events from Cisco IOS software, and access peripherals attached to Cisco ISRs.
Applications can be tightly integrated with Cisco ISRs: this is a key advantage of using Cisco AXP for hosting, compared to using other server-based solutions. Cisco AXP hosts and executes an operating system in a virtualized environment.
The execution environment separates the application space from the router space, providing an extensible and flexible platform for hosting applications.
Figure 2 Cisco Application eXtension Platform on the Cisco ISR
Cisco AXP supports basic watchdog functionality to start, stop and monitor applications written in Java, C/C++, Perl, Python, and Bash. Cisco AXP supports tools for compiling applications in an x86-based Linux environment.
Virtualization
Cisco AXP uses virtualization at the operating system level to create an environment for multiple applications to run as stand-alone components. Virtualization partitions resources to support concurrent execution of applications in multiple virtual machines/virtual instances.
The advantages of virtualization in Cisco AXP are:
•
•
•
•
Note
Virtual Instances
In Cisco AXP, a virtual instance is a container within a virtual server. Process isolation gives security, and results from processes running in one virtual instance not being able to see processes running in another instance. This technology applies a change root barrier. If the application software is installed under /home/app1 and then application processes start, the directory /home/app1 becomes the root directory for the application processes. Processes can only access directories below this root directory and do not have permission to escape from /home/app1.
User-level processes are virtualized: one Linux kernel is used throughout the system, which uses a low amount of memory and has a low scheduling overhead with high speed IO access. The system provides near native OS performance.
Your application software (which can contain multiple processes) is packaged into a Super Lightweight Installer Mechanism (SLIM) format, using the Cisco AXP packaging tool. You can then install the application package into the root directory of a virtual instance. Within the virtual instance, the application has its own guest OS. The host OS manages all the guest OSs.
Files delivered by a third party cannot be shared between virtual instances. Cisco AXP does not support applications in different virtual instances having read or write access to a file in a shared area.
To further improve security, the shell environment of the host OS is not available by default. Only the CLI within the guest OS is available for managing the operating environment. You, the developer, control shell access to the guest OS.
Devices are not virtualized and are shared across all virtual instances. Therefore, IO operations do not incur additional overhead.
Network interfaces cannot be virtualized. However, you can use a "virtualized loopback interface" mechanism. See the "Loopback Interfaces" section.
Interface hiding occurs in a virtual instance. Network routing tables are not virtualized; however, multiple routing tables can be configured in Cisco AXP.
Figure 3 Cisco AXP Virtualization
Virtualization is achieved by kernel-level isolation, allowing multiple virtual instances to run simultaneously, and use common resources.
Note
Loopback Interfaces
Network interfaces cannot be virtualized. An application can use a loopback to communicate internally without worrying that an interface is being used by other virtual instances or the host.
Cisco AXP provides a way to virtualize loopback interfaces for each instance.
For example, a virtual interface of the loopback (lo:2, lo:3) and its corresponding address (127.0.0.2, 127.0.0.3) is provided to a virtual instance.
The default loopback (127.0.0.1 and lo) is reserved for the Cisco AXP host loopback interface, and is also accessible in each virtual instance.
The /etc/host file of each virtual instance is populated with the virtualized loopback interface and the Cisco AXP host loopback interface. For example, if an application is installed to Cisco AXP, its /etc/host file should look like this:
127.0.0.x localhost.localdomain localhost127.0.0.1 apprehostIf you issue the command netstat in the virtual instance, this shows that "lo" is associated with "127.0.0.1", and "lo:x" is associated with "127.0.0.x".
x is a number ranging in value from 2 upwards, depending on the number of virtual instances.
This number is dynamically allocated, so applications must not assume that x stays the same.
For example, when a new application is installed, the new application can be assigned x while the original application can be assigned x+1. Applications should instead rely on "localhost" being their own virtualized loopback interface.
127.0.0.1 is assigned to "apprehost" and 127.0.0.x is dynamically assigned to "localhost".
Note
Dedicated Application Resources
Cisco AXP provides a predictable and constant set of resources such as CPU, memory, and disk space. For configuring resource limits, see the "Setting Resource Utilization Limits" section in the Cisco AXP User Guide.
CPU Resources
An indication of the CPU resources that are available for different service modules is specified as a CPU index. The CPU index is a value that is relative to a base value. The base value of 10000 is assigned to the following configuration:
1.0 GHz Celeron M CPU and a NME_APPRE_302-K9 service module.
For example, the CPU index for the service module AIM_APPRE 102 is 3000.
An application package uses approximately the same amount of CPU resources on any service module. The total available CPU (Index) or CPU RAM varies depending on the service module as shown in the Available CPU (Index) and Available RAM (MB) columns of Table 1.
Memory Resources
Cisco AXP does not use disk swapping for virtual memory. Therefore, the amount of memory available to an application is limited by the physical memory of the system.
In the context of virtual instances, the memory limit specifies the maximum memory available for each virtual instance. When memory overcommit is enabled, if the total memory usage within the virtual instance exceeds the memory limit (specified in MB), then processes within the virtual instance are killed.
Application Packaging Overview
Cisco AXP supports a range of applications and programming languages, including applications written in Java, C, and Bash scripts. To install your application in a virtual instance, you must first package your application. For information on how to package the application and sign the package, see the "Packaging Tool" section. To use the packaging tool you need to obtain a developer's certificate from Cisco. You sign the application package using your third party private key.
System and application packages are summarized in the following sections:
•
Core System Package
The core system package is preinstalled on all Cisco AXP service modules, and is necessary to support applications and virtualization. A Cisco Linux distribution OS is used in the Cisco AXP virtual instance.
The Cisco AXP OS gives support for virtualization, and includes kernel and system utilities such as Linux commands, Router Blade Communication Protocol (RBCP), and a CLI server.
The host Operating System (host OS) consists of a kernel of the core system package that is shared by all virtual instances running on the service module.
The guest Operating System (guest OS), is an embedded Linux OS that shares the kernel of the host OS. The guest OS includes virtual environment setup and management utilities, and software required for installing the application. The guest OS shares the Linux kernel of the core system package in the host OS.
For a list of commands available in a guest OS, see the "Appendix B: Commands in Guest OS" section.
Packages can be divided into the following two types:
•
Cisco AXP Infrastructure Add-on Packages
Cisco AXP infrastructure add-on packages extend the capabilities of the guest OS. In this guide these packages are also referred to as either Cisco add-on packages, or value-added service APIs.
Your application package can be packaged with a Cisco add-on package as a dependency. These add-on packages are created and signed by us and cannot be modified by third party developers.
Cisco add-on packages each have a separate intended function to depending on the purpose of the application in the hosting environment.
Files in Cisco add-on packages are shared on a read-only basis between multiple virtual instances. The Cisco AXP host OS that supports multiple virtual instances. One copy of a Cisco add-on package is stored in a file system created and signed by us. Copies of a Cisco add-on package are instantiated in multiple virtual instances.
Examples of Cisco add-on packages include: Cisco IOS Service API, and Perl. See the "Infrastructure Add-on Packages" section.
Hosted Application Packages
Hosted application packages are created by third party developers. In this guide these packages are also referred to as third party application packages. These application packages contain the binaries, supporting libraries, and any required data files to support the application. Each third party application package is signed using a developer's private key and verified using the developer's certificate. Third party application packages are hosted only in Cisco AXP virtual instances.
Each third party application is loaded into one virtual instance. (There is one virtual instance for each application.) Several application packages can be bundled together. For more information on bundling, see the "Bundling" section.
Figure 4 Cisco AXP Add-on Packages
Cisco AXP Certificates
Cisco AXP uses cryptographic signatures to verify packages that are signed by us to prevent unauthorized software to be loaded onto the operating system.
Signatures are also used to verify application packages developed by third parties. Third parties do not have access to our private keys for package signing and must manage their own public or private key pairs. The process for signing application packages is summarized in Figure 5.
Figure 5 Cisco AXP Application Packaging
Permission to install third party software on Cisco AXP is managed by us and is granted by providing you (the third party) with a software development authorization certificate. The certificate is a checksum of the third party X.509 certificate. See Figure 6 and Table 2 to see the process steps for obtaining permission.
Figure 6 Cisco AXP Certificates
Table 2 Steps in the Development Authorization Process
Step
Description
Third party generates a certificate request (private/public keys).
Third party requests a signed certificate from the certificate authority.
Certificate authority responds to the third party request, by providing a signed X.509 certificate1 .
Third party requests software development authorization from Cisco (includes signed certificate from certificate authority).
Cisco authorizes the signed certificate.
Cisco replies with a software development authorization certificate2 .
1 The third party is responsible for providing the signed X.509 certificate to Cisco. (Step 3)
2 The software development authorization certificate is a file that contains an encrypted checksum authorizing the third party to install software in Cisco AXP. The authorization certificate only applies to an X.509 certificate signed by the certificate authority (Step 3 in Table 2.).
Notes on Steps in the Authorization Process
During application packaging, the third party includes the following items in the package:
Cisco authorization certificate, third party certificate, third party private key, and third party application.The checksum of the authorization certificate is checked before the authorization certificate's public key is used to verify the application. The certificate can be used to verify that the application files are installed with the application package. The authorization certificate is held in the application's manifest file and stored outside the virtual environment of the host OS.
If the target hardware contains a device to securely store cryptographic keys or certificates, then
Cisco AXP does not use the third party's key to verify software integrity. The installed software is re-signed using a private key tied to the hardware and is verified using the corresponding public key.The Cisco AXP software development kit (SDK) provides third parties with the tools for packaging and signing their application files, and for attaching their certificate to the application bundle.
Running Applications on the Guest Operating System
An embedded Linux guest OS is automatically included in the application software dependency list. The guest OS contains a set of basic Linux binaries and libraries. The libraries are listed in "Appendix C: Libraries in Guest OS". The guest OS shares its kernel with the host OS. After being installed on the service module, every application instance has access to its own guest OS and may add or modify its own components.
In the following sections, starting an application is explained in "Application Startup", and monitoring the status of an application is described in "Application Status Monitoring".
The Guest OS is further explained in the following sections:
•
•
•
For information on libraries and commands available in the guest OS, see the "Appendix C: Libraries in Guest OS" section and "Appendix B: Commands in Guest OS".
Note
Application Startup
You can run your application using one of the following two startup processes:
Automatic Startup
Information about the Automatic Startup Process
Before starting your application using a startup script as explained in the "Preparing to Run an Automatic Startup Script" section, we advise you to specify the library path in the LD_LIBRARY_PATH variable.
When the virtual instance starts, a default Cisco AXP environment is used, which determines the available libraries—this environment is set to enable successful startup of the virtual instance.
When your application startup script starts, it uses this default environment which may cause problems for your application.
To avoid the problem of accessing libraries that are not available, enable reference the PATH and LD_LIBRARY_PATH environment variables.
(The LD_LIBRARY_PATH variable is also explained in the "Library location and LD_LIBRARY_PATH" section.)
How to Prepare the Startup Script
This section contains the following tasks. You may not need to perform all of these procedures.
•
•
Referencing the Environment Variables
To create or modify environment variables:
Choose one of the following two options:
•
–
export LD_LIBRARY_PATH=/lib:/usr/lib:/opt/IBM-ME-2.2.2/jre/binexport PATH=/sbin:/usr/sbin:/bin:/usr/bin:/opt/IBM-ME-2.2.2/jre/bin–
. /etc/profileOR
•
export LD_LIBRARY_PATH=/lib:/usr/lib:/opt/IBM-ME-2.2.2/jre/binexport PATH=/sbin:/usr/sbin:/bin:/usr/bin:/opt/IBM-ME-2.2.2/jre/binPreparing to Run an Automatic Startup Script
To prepare your automatic startup script:
Step 1
For example, create a script startHelloWorld.sh in build source directory /etc/rc.d/init.d
Step 2
S priority softlinkname
Startup Softlink: Example
In this example the softlink to startup script startHelloWorld.sh has a priority of 98 (range is 00-99). The startup script is in directory /etc/rc.d/init.d
S98helloworld
If you use the ls -l command in directory rc3.d, the following output shows how the softlink S98helloworld links to startHelloWorld.sh:
lrwxrwxrwx 1 uname uname 26 Aug 11 13:40 S98helloworld -> ../init.d/startHelloWorld.shStep 3
K priority softlinkname
Kill Softlink: Example
In this example the softlink to kill script endHelloWorld.sh has a priority of 98 (range is 00-99). The kill script is in directory /etc/rc.d/rc6.d
K98helloworld
Manual Startup
For manual startup, perform the following steps.
Step 1
–
–
Step 2
<name> is the application's name.
Step 3
–
–
Step 4
Obtaining Console Access for the Application
To obtain console access for the application choose one of the following procedures:
•
•
Console Access using Application Development Package
To obtain console access using a debug package as a dependency, perform the following steps.
Step 1
Step 2
Step 3
Step 4
Your application has console access to the guest OS shell using the command linux shell.
Console Access using Postinstall Script
To obtain console access using a postinstall script, perform the following steps.
Step 1
For example, create a bash file /source/bin/login.sh, where /source is the build directory.
login script: Example
#! /bin/sh/bin/bash --loginStep 2
For example, create script /source/bin/postinstall.sh, where /source is the build directory.
postinstall script: Example
#! /bin/shln -s /bin/login.sh /bin/consoleStep 3
chmod 755 /opt/tcptrace/postscripts/postinstall.shStep 4
Your application now has access to the guest OS shell by using the command connect console.
Application Status
An application must invoke the notification command to signal its status. See the "Notification" section. For example, this is necessary in order for configuration CLI commands to detect when the application is available.
An application that sends a status code indicating that it is up and running, expects configuration commands to arrive at any time. The possible status codes are shown in Table 3.
Table 3 Status Codes
INITIALIZING
Application is starting up.
ALIVE
Application is running.
DOWN
Application is down.
Notification
Notification command location: /bin/app_status_notifier.
Application name and status code are passed as parameters or arguments to the notification command.
Notification: Example:
#/bin/app_status_notifier myapp ALIVEViewing an Application's Health
To view the health of an application perform the following steps.
Step 1
<name> is the application name.
Step 2
For further information, see "Viewing the Application State" in the Cisco AXP User Guide.
Application Status Monitoring
An application must include one or more watchdog scripts or executable files bundled in the application package so that application status monitoring can be used.
Two methods of monitoring the application are described in the following sections.
Watchdog Scripts
If the application state is "online" and application health is not "DOWN", the application is monitored by the application status monitor.
The application must provide one or more watchdog scripts (also known as health check scripts or health check executables). Shell scripts and C executables are supported. The number of scripts is application dependent.
Bundle the watchdog scripts in the application package.
An application has its own way of determining if another application is running. For example, an application may check the Process Identifier (PID), or check the response to a "ping".
Watchdog scripts must be placed in the predefined directory /opt/app_status_monitor/watchdogs/
The watchdog scripts directory is in the application's vserver directory, and needs to have executable permissions. All watchdog scripts inside that directory will be invoked, and if you want to ensure the correct ordering for script invocation, you can follow the following template for naming a watchdog script:
W**<name>.sh, where ** is a two digit number. For example, one watchdog script is called W01myapp.sh.
The application status monitor has a heartbeat of 5 seconds, where 5 seconds = 1 interval. Five seconds is the minimum interval that the application status monitor requires for monitoring.
When any one watchdog script returns a non-zero status code, information for this failed watchdog will be logged, including: watchdog name, return status, and time of failure. A recovery counter counts how many times that failure occurs, and works as a delay in taking any action. A recovery counter of 3 means that the application monitor has run the monitoring for 3 iterations and is either getting non zero return status, or the watchdog has been running for over 3 monitor intervals and is not returning. The configurable recovery threshold determines the number to which the recovery counter increments to before taking the next action. When the recovery threshold is reached the virtual instance is restarted. After the virtual instance is restarted, application status monitoring continues, and the monitoring steps above continue. There is no limit on how many times the virtual instance restarts.
To configure the monitor interval, see the "Status Monitor" section. Also see the Cisco AXP User Guide. Each script or executable needs to return a status code.
•
•
Watchdog Script: Example:
#!/bin/bashAPP=test.sh APPNAME_NO_EXT=test PID_FILE=/var/run/${APPNAME_NO_EXT}.pidif [ ! -e $PID_FILE ]; then exit 1; fiPID_FROM_FILE=`cat ${PID_FILE}` for x in `ps -ef|grep $APP |awk '{print $2}'` do if [ $x == "${PID_FROM_FILE}" ]; then exit 0 else exit 1 fidoneIn this example watchdog script, the startup script must have populated the /var/run/<app>.pid file with the pid of the currently running application. The startup script should also account for various scenarios such as:
•
•
When any watchdog script returns a nonzero status code, information is logged such as name of watchdog, return status, and the time of failure. A recovery counter counts how many times failures happen. A recovery counter value of 3 indicates one of the following two conditions:
•
•
There is a configurable recovery threshold that decides the value that the recovery counter reaches before taking the next action. When the recovery threshold is reached, the virtual instance is restarted.
After the virtual instance restarts, the application status monitor continues to run, and the above two conditions are tested again. There is no limit on how many times the virtual instance restarts.
Status Monitor
The following example commands include show status-monitor, and commands to configure the monitor interval and recovery threshold. For more information, see The Status Monitor in the
Cisco AXP User Guide.•
blade# app-service myapp(myapp)# show status-monitorApplication: myapp1Monitor status: PASSEDMonitor in progress: NoLast executed watchdog: W01myapp1_test.shLast executed date: Tue Jul 10 10:22:06 PDT 2007Last failed watchdog: W01myapp1_test.shLast failed return code: 4Last failed date: Mon Jul 9 12:34:18 PDT 2007Last restarted date: Mon Jul 9 12:33:32 PDT 2007Recovery threshold: 6Monitor interval: 2•
blade# config terminal(config)# app-service myapp(config-myapp)# status-monitor monitor_interval 24 recovery_threshold 10(config-myapp)# end
Configuration File
In addition, you can provide a default configuration by using a configuration (config) file that is packaged together with your application.
The config file name and path:
/opt/app_status_monitor/config/configEach record in the config file is in the following format:
[monitor_interval | recovery_threshold] [1-99]The default value monitor_interval is 12. The application is monitored every 12 heartbeats. If the monitor interval is 12, then the monitor is active on each virtual instance every minute.
The default value for recovery_threshold is 5.
Note
config file: Example
monitor_interval 50recovery_threshold 10Configuration values, (such as the values of 24 and 10 set in the Change the monitor interval and recovery threshold example above), take precedence over the config file values. The config file only serves as a source of default values when the application is installed.
CLI Service API
The CLI service API allows your application in the guest OS to interact with the CLI server in the host OS.
For example, Java application code can issue EXEC mode commands or configuration mode CLI commands.
Care must be taken to issue commands suitable for a particular mode. For example, show run should be run in EXEC mode—if it is not run in EXEC mode, an error occurs. The supported languages for programming/scripting languages are supported: C, C++, Java, Python, and Perl. CLI service APIs for these languages are shown in the following sections.
CLI commands can be submitted in batches by the application within a single instance. This is useful in automating repetitive tasks such as reconfiguration after an image refresh.
The Cisco AXP SDK contains the libraries and modules required for writing CLI service EXEC mode or configuration mode commands. The languages supported by the Cisco AXP SDK and the associated libraries/modules are listed in Table 4.
Table 4 Files for CLI Service API
C/C++
/include/appreapi.h
/lib/libappreapi.soJava
/jar/appreapi.jar
Python
/python2.3/AppreAPI.py
Perl
/perl/AppreAPI.pm
CLI Service APIs
Java API
public int exec (AppreMessage msg);public int config (AppreMessage msg);The Java bean object AppreMessage contains both the request and response string.
After the code has run, the returned status code indicates completion/failure. For status code values, see Table 5.
public class AppreMessage{private String _response;private String _request;public void AppreMessage(){this._response = "";this._request = "";}public String getRequest(){return this._request;}public void setRequest(String request){this._request = request;}public String getResponse(){return this._response;}public void setResponse(String response){this._response = response;}}C/C++ API
Note
int appreapi_exec(AppreMessage_t* msg);int appreapi_conf(AppreMessage_t* msg);free (msg.response);AppreMessage_t is a struct containing the request and response string.
After the code has run, the returned status code indicates completion/failure. For status code values, see Table 5.
typedef struct AppreMessage_t{char* request;char* response;int size;} AppreMessage_t;Perl API
sub exec (request)sub config (request)The request string is input and the status code value is output. For status code values, see Table 5.
Python API
sub exec (request)sub config (request)The request string is input and the status code value is output. For status code values, see Table 5.
Bash API
appreapi [--mode name] [[--file filename] | [cmdlist]]The request string is input and the status code value is output. For status code values, see Table 5.
CLI Service API Examples
In the following examples, commands are issued by passing a string to a function/method such as request (for C) or setRequest (for Java). More than one command may be passed at one time, by separating each command with a comma. For example, to use setRequest( ) to call two or more system commands:
msg.setRequest(cmd)where cmd is a string containing a sequence of commands separated by commas.
For example,
String cmd = "show run,show trace"The following sections show code fragments that implement AppreMessage in the main programming/scripting languages of C/C++, Java, Perl, and Python.
C/C++: Example
#include "appreapi.h"int main(int argc, char** argv){char buf[] = "show run";AppreMessage_t msg;msg.size = 0;msg.response = NULL;msg.request = buf;int status = APPRE_FAIL;status = appreapi_conf(&msg);status = appreapi_exec(&msg);return status;}Java: Example
import com.cisco.aesop.apphosting.appreapi.*;public static void main (String[] args){int status = 0;CommonServiceImpl apiCall = new CommonServiceImpl();AppreMessage msg = new AppreMessage();msg.setRequest("show run");status = apiCall.exec(msg);status = apiCall.config(msg);}In the above example the Java class CommonServiceImpl implements the API access service.
The class has two methods for exec and config mode:
public int exec (AppreMessage msg)public int config (AppreMessage msg)Perl: Example
use AppreAPI;$api = new AppreAPI::AppreAPI();$req = "show run";($val, $res) = $api->exec($req);($val, $res) = $api->config($req);Python: Example
from AppreAPI import *api=AppreAPI()status, response = api.exec(request)status, response = api.config(request)Logging Support
Cisco AXP provides logging support for applications that include a syslog or log4j logging facility, and file rotation of logging files. Different logging levels can be set. If an error occurs with a level below the logging level, the error is not reported in a log file. For more information on logging errors, see the "Logging" section.
SNMP
Your application can use SNMP. net-snmp code is located in the following two places:
•
•
The net-snmp library uses a socket for internet access.
Further details:
•
•
•
Infrastructure Add-on Packages
Cisco infrastructure add-on packages are packages provided by us, with additional functionality for applications.
Package names have the format: <package>.<platform>.<version>.pkg
A package name of "axp-tomcat5.nme.1.1.1.pkg" shows the package is a tomcat application, the platform is NME , and the version is 1.1.1.
The associated payload file for each add-on package has the suffix ".prt1"; for example "axp-tomcat5.nme.1.1.1.prt1" (the version number in this example, is the same as the version number in the Cisco AXP host OS package: axp-k9.<platform>.<version>.pkg).
Add-on packages:
Installing Add-on Packages
Step 1
Step 2
Step 3
–
–
Step 4
Cisco AXP User Guide.
Cisco AXP Add-on Packages
Cisco AXP provides the following add-on packages.
•
•
•
Tomcat
Package name: axp-tomcat5.<platform>.<version>.pkg
An example package name is axp-tomcat5.nme.1.1.1.pkg
Use the tomcat package to embed the Tomcat 5.5 servlet container in a virtual instance.
Application SSH
Package name: axp-ssh-4.6p1-k9.<platform>.<version>.pkg
An example package name is axp-ssh-4.6p1-k9.nme.1.1.1.pkg
For further information, see the "Application SSH package used in production for SSH Tunneling" section "SSH Tunneling" section.
Application Development Package
Package name: axp-app-dev.<platform>.<version>.pkg
An example package name is axp-app-dev.aim.1.1.1.pkg
Access
Guest
