Downloads |
General Questions
Q. What does AXP stand for?
A. Application eXtension Platform.
Q. What is AXP?
A. AXP is a Linux blade that runs in the Cisco integrated services router and allows third-party applications to be tightly integrated with the router using APIs. AXP provides an application hosting infrastructure that affords Cisco integrated services router customers the opportunity to run all or portions of their branch applications on an integrated services router service module. The AXP will also be available to commercial application vendors and customers as a new platform capable of running their applications inside of an integrated services router, rather than on a traditional standalone server. AXP provides a powerful platform to create complete solutions with the integrated services router.
Q. Can anyone develop an application and install it on AXP?
A. Developers need to engage through the AXP Development Partner Program.
Q. Are any prepackaged application solutions available for sale?
A. The AXP go to market includes both platform sales (AXP sold as open platform) as well as solution sales (AXP sold as part of larger solution ecosystem). Cisco is building solution practices around primary markets such as payment systems, workforce management, and unified communications. Most of these solution sales will be reference sells, whereas a small number of them will be sold with third-party applications on the Cisco price list. In any case, there a number of prepackaged, validated solutions will be cultivated and marketed as part of the overall AXP go to market.
Q. What operating systems can run on AXP?
A. Today, Linux is the only supported OS.
Q. Is Windows supported on AXP?
A. Not today.
Q. Which integrated services router chassis support the AXP service modules?
A. Table 1 lists integrated services routers that support the AXP service modules.
Table 1. Integrated Services Router Support
Positioning Questions
Q. What is the difference between AXP and Application Oriented Networks (AON)?
A. AXP is an open platform that is built to host applications wholly utilizing standardized Linux tools and libraries. The AXP integration APIs allow the application to use the information and resources of the router for analysis, packet process, and dynamic router interactions. AON is not an application hosting platform but provides messaging middleware functions, which are typically required for application to application communication. AXP could be deployed in a complementary fashion with the AON module. Here, the AON module could be used to run messaging middleware interacting with applications hosted on an AXP module.
Q. What is the difference between AXP and Wide Area Application Services (WAAS)?
A. They are very different products. AXP is purpose-built with one objective in mind: to provide a robust appliancelike hosting infrastructure inside an integrated services router for hosting custom or third-party applications. This objective is enhanced with additional integration features such as virtual containers, monitoring/configuration/Embedded Event Manager (EEM) APIs, integrated services router serial-port virtualization, and a software development kit (SDK). WAAS is purpose-built to accelerate WAN traffic so as to provide LAN-like performance to branch office application deployments.
Q. What is the difference between AXP and WAAS virtual blades?
A. Both AXP and WAAS virtual blades support application consolidation in the branch and can be used to meet different customer needs. AXP provides application hosting and network integration capabilities in a module form factor for Cisco integrated services routers, whereas WAAS virtual blades provide application hosting on high-end WAAS appliances. Salient differences include:
• Different form factor-The Integrated Services Router module compared to high-end WAAS appliance form factor (virtual blades are not supported on WAAS modules in integrated services routers).
• AXP supports hardened Cisco Linux to run multiple applications, whereas WAAS virtual blade provides OS-level virtualization to run certified applications on commercial OS platforms.
• AXP provides an SDK to enable customers and partners to build custom applications using network APIs and built-in tools, while WAAS virtual blade is targeted to host certified commercially available applications.
• AXP is a low-cost solution for deploying branch applications, whereas WAAS virtual blades offer high-end server-class hardware for applications that need more resources and/or could justify the price premium. There are no extra costs of OS for AXP, and support is included in the Cisco SMARTnet® Service for the router.
Go To Market Questions
Q. What are the value propositions to an Independent Software Vendor ?
A. ISV value propositions include:
• Use: strategic business value of integration
• Scale: access to Cisco field and channels
• Competitive advantage: new business models
Q. What are the value propositions to a systems integrator or Managed Services Provider?
A. Systems integrator and MSP value propositions include:
• New revenue: increased route to market
• Stickiness: account control
• Differentiation: solution-based sales
Q. What are the value propositions to a direct customer?
A. Direct customer value propositions include:
• Single-box solution
• Lower total cost of ownership (TCO)
• Green solution
Technical Questions
Q. Is an SDK available to support the development of applications on AXP?
A. Yes. The SDK is downloadable with the purchase of an AXP product. It includes various tools for packaging applications and preparing them for AXP installation.
Q. How is the AXP service module connected to the network?
A. Both the Enhanced Network Module (NME) and AIM AXP service modules connect to the integrated services router backplane using an internal Gigabit Ethernet connection. That connection results in an integrated services router interface (for example, Integrated Service Engine 1/0 or Service Engine 0/0) and an AXP interface (for example, eth0). Subinterfaces can be created under each of these as well (subinterfaces are not configurable today on AIM service modules). The NME service modules have an external Gigabit Ethernet interface as well.
Q. Can a customer run a passive application on the AXP service module (for example, network analyzer)?
A. Yes. The AXP service module can be configured to receive packet copies of network traffic received on a specific interface on the integrated services router by using either the AXP Promiscuous Packet Capture or the Cisco IOS® Software Router IP Traffic Export (RITE) feature configurations. (Note: The AXP Promiscuous Packet Capture feature is not available in the current AIM module.) These features allow a passive application to run on an AXP service module (for example, sniffer/packet analysis).
Q. What kinds of management tools are available on the AXP service module?
A. For management of the AXP application environment, Prosyst, an ISV development partner, provides its management tool, mPRM, which provides centralized installation of AXP OS and application images, remote configuration, and monitoring of system and application health. The components of mPRM include a centralized UI and server and agents packaged as standard AXP packages that run on the AXP service module.
Support in CiscoWorks LAN Management Solution (LMS) is planned for a future release in 2008 and will provide centralized and remote installation and configuration of the AXP blade and OS.
Q. What version of Linux does Cisco provide?
A. Cisco's Linux is derived from mainstream distributions, is based on a modern kernel version (2.6.x+), but has been hardened for security and manageability purposes.
Q. If there is an AXP service module failure, will it adversely affect the host integrated services router?
A. No. Although the AXP service module consumes power and receives packets from the integrated services router, it uses its own CPU, RAM, and storage as resources available for both the host Linux OS and any/all applications running in the environment. In other words, AXP has its own OS and hardware resources completely separate from Cisco IOS Software and integrated services router hardware resources.
Q. How does one develop an application for the AXP service module?
A. Both existing and newly developed applications must be ported to the AXP runtime environment by packaging them using the AXP SDK, which ships with the AXP hardware and software. The SDK package tool creates installation packages that can be loaded on the AXP blade. AXP developers are authorized by Cisco using the AXP Development Partner Program and require an authorization key in order to perform packaging of software.
Q. How does one install an application onto an AXP service module?
A. The two package files (.pkg and .prt1) are placed on an FTP server to which the AXP service module has access. The "install" command is run on the AXP service module, pointing to the .pkg file. The AXP system takes care of all the installation and upgrade complexity. Applications can be bundled with the OS in a single installation package or installed individually. The process is similar to how Cisco IOS Software images are installed or upgraded in the integrated services router and can be performed by the end customer.
Q. What are the hardware specifications of the AXP service module?
A. Table 2 lists hardware specifications.
Table 2. Hardware Specifications
|
Service Module |
CPU |
RAM |
Storage |
|
AIM-102 |
300-Mhz Intel Celeron |
256 MB |
1-GB Flash |
|
NME-302 |
1.0-GHz Intel Pentium |
512 MB |
80-GB hard drive |
|
NME-522 |
1.4-GHz Intel Pentium |
2 GB |
160-GB hard drive |
Q. Are there any additional security features one gains when loading an application on the AXP?
A. Applications must be packaged using the AXP SDK package tool, which requires a software developer key such that when the install process is invoked, the AXP system will check the viability of the key used. This prevents rogue applications from being loaded onto an AXP service module.
Additionally, the application deployment architecture can be configured to utilize router security features (firewall, intrusion prevention systems [IPSs], access control lists [ACLs], Network Address Translation [NAT]) to help ensure an additional hardened layer exists surround the application.
Q. What Linux distribution and kernel are running on the AXP?
A. Today, the AXP is running Linux kernel 2.6.14.3 and glibc version 2.3.5. The AXP OS allows developers to overwrite and replace the standard libraries, including glibc, with versions from other Linux distributions, providing they are compatible with the AXP kernel. The standard AXP libraries are compatible with Fedora Core 4.
Q. Does AXP support virtualization software such as VMware or Xen?
A. No. Today, the AXP OS does support hardware-based virtualization technologies such as VMware or Xen. AXP runs a single Linux kernel and supports a software virtualization technology that allows developers to independently develop and host multiple applications. The AXP Virtualization Manager allows developers to segment their applications while guaranteeing CPU, memory, and disk resources. Each application runs in its own environment, allowing it to be installed, upgraded, and debugged independently of the AXP OS and the other applications.
Q. How many applications can I run on a single AXP service module?
A. There is no hard limit to the number of applications that can run on a single AXP service module. This number is highly dependent on the system resources requested by each application during installation. Cisco has tested as many as 16 virtual instances running simultaneously on a single AXP service module.
Q. Can multiple applications running on a single AXP module have different IP addresses?
A. Yes. AXP provides very flexible IP management, including multiple physical as well as support for virtual instances. IP addresses can be optionally bound to one or more applications, providing the flexibility to segment or share as necessary.
Q. Can I populate a single integrated services router with multiple AXP service modules?
A. Yes. There are no hard or soft limits to the number of AXP service modules loaded into a single integrated services router chassis.
Q. Is there serial device support?
A. Yes. The asynchronous serial interfaces on the integrated services router chassis can be utilized by an application running on the AXP service module. The AXP serial API exposes the serial devices connected using Cisco IOS Software as standard Linux serial devices.
Q. Is there external storage support today?
A. No. There are plans to support USB-based external storage devices in the future. The NME service modules have USB ports on them.
Q. Can I modify the Linux kernel modules?
A. Not as a standard feature. For extreme cases with high revenue potential, ARTG will consider allowing access on a case-by-case basis.
Q. What development environment does Cisco recommend?
A. The AXP was developed to run on a variety of Linux distributions. Developers use their existing tools to build their applications and then package the binaries and required libraries for installation on the AXP module.
Q. What APIs are available to applications running on an AXP?
A. Monitoring, configuration, and EEM APIs are available. These APIs allow an application to monitor and control various aspects of the integrated services router.
Q. Is it difficult for ISVs to port their existing applications to AXP?
A. The AXP product is composed of three components: the hardware, the Linux environment, and the SDK. The SDK makes porting existing commercial applications straightforward. However, depending on the complexity of the application and the types of Linux libraries used, the port might not be trivial. As a general rule, if the application was built originally to run on Linux, the time to port is greatly reduced. Windows applications (for example, .NET) will not run on an AXP service module.
Support Questions
Q. What is the support model for AXP? Are there unique aspects to it outside of Cisco SMARTnet Service?
A. Two basic Cisco support channels are applied to AXP deployments:
• Cisco SMARTnet: covers the integrated services router and the AXP service module
• AXP developer/partner support contract: covers development aspects
Support of the application resides with the provider or owner of the application, which could be the customer, integrator, or ISV.
Q. How does one become an AXP development partner?
A. Generally, there is an evaluation and application process for any party. There are two general kinds of development partners: AXP developers and solution partners, with different processes for both. For more information, visit the partner links at http://www.cisco.com/go/axp.
Q. How does the AXP Development Partner Program relate to the Cisco Technology Developer Program and other programs?
A. The AXP Development Partner Program (AXPP) uses Cisco Technology Developer Program, Developer Services, Industry Solution Development Partner (ISDP) channels, and other Cisco programs for all program aspects. It is a higher-level framework to help ensure that there is one consolidated place for information about how to engage successfully with Cisco in developing, selling, and deploying applications on AXP in the integrated services router.