Guest

Cisco Application Extension Platform

Application eXtension Platform Networking Application Note

  • Viewing Options

  • PDF (274.7 KB)
  • Feedback

Introduction

At the most fundamental level, the network is relied upon to provide connectivity between application nodes in a distributed environment. Each application instance in a network must bind to a network interface in order to send and receive data packets. On a standard server platform, this is a very common task that in many cases is done transparently when the application is installed. With the Cisco ® Application eXtension Platform (AXP), the application resides inside of an Integrated Services Router (ISR) running on top of either an enhanced network module (NME) or an advanced integration module (AIM).
AXP also provides a virtualization environment, in which multiple applications can run simultaneously in their own virtual containers, implying that each application requires a unique set of network bindings to service its particular network connectivity needs. It becomes imperative that the network administrator maintain a strategy to manage this connectivity so as to meet the needs of each application instance running on a single AXP blade.
Additionally, with AXP being the integration vehicle between the network and the application, there is a definite shared responsibility for achieving highly available services.

Audience

This document is intended for network design architects and support engineers who are responsible for planning, designing, implementing, and operating networks. The reader of this document should be familiar with the AXP product as well as with Cisco routing technologies.
Cisco AXP:
<link here to CCO page>
Cisco Integrated Services Routers (ISR):

Document Objectives

This is an application note, which means that its primary objective is to articulate recommended best practices for accomplishing a specific functional goal in the network. In this case, the document describes common use cases and deployment scenarios and the corresponding configuration recommendations for achieving those scenarios.

Overview

When installed in an ISR, the AXP service module can be configured in multiple ways to afford network connectivity to the applications running on the module. There are three main steps in accomplishing this task:

1. Assign an IP address to the ISR side of the internal Gigabit Ethernet interface.

2. Assign an IP address and default gateway to the AXP side of the internal Gigabit Ethernet interface.

3. Bind application vserver instance(s) to a specific interface definition.

Figure 1 gives an overview of AXP network connectivity. In the simplest configurations, one simply assigns an IP address on some subnet to the ISR side of the internal Gigabit Ethernet connection, then assigns an IP address and default gateway to the AXP side of the internal Gigabit Ethernet connection, and finally, binds one or more applications to the AXP side of the connection.
However, for various reasons relating to applications requiring multiple unique IP addresses per instance and multiple vserver instances running simultaneously on a single AXP module, an administrator has the flexibility to create subinterfaces and subsequently bind them to unique application interfaces.
Furthermore, an administrator may also configure VLAN trunking via 802.1Q encapsulation on these interfaces.

Figure 1. Overview of AXP Network Connectivity

Based on customer feedback, this document covers the following four deployment scenarios:

1. One IP address for one or more applications

2. Multiple IP addresses for one or more applications

3. Multiple IP subnets for one or more applications

4. External Gigabit Ethernet interface

AXP Internal Interface Fundamentals

Each AXP module in an ISR has a unique relationship with the ISR, in that there is an internal Gigabit Ethernet interface on the ISR side (ISE1/0) as well as an internal Gigabit Ethernet interface on the AXP side (eth0) of the physical connection (see Figure 2). This connection is created when an AXP blade is inserted into the ISR chassis. As a result, both sides of this internal connection must be configured separately. This document discusses some variations for accomplishing this exercise.
With the enhanced network module (NME) version of the AXP platform, there is also an external Gigabit Ethernet interface (eth1) available to applications.

Figure 2. Internal Gigabit Ethernet Connection

Note: Parts of this document discuss how to configure subinterfaces on the AXP service module. The currently shipping AIM hardware version does not support the configuration of subinterfaces. Future releases of the AIM hardware will support such configurations.

IP Numbered vs. IP Unnumbered

As a precursor to the more in-depth sections of this document, it is important to understand that there are two basic options for configuring the eth0 interface on the AXP service module.
This document assumes that the IP Numbered scenario is used, and the examples contained herein reflect this assumption. In situations in which a network administrator does not wish to consume a separate subnet for the internal Gigabit Ethernet connection between the AXP service module and the ISR, the IP Unnumbered configuration option can be applied.
Figure 3 depicts a typical scenario in which a network module is connected to an Integrated Services Router. The following interfaces have been marked.

1. Router interface to external link (Gigabit Ethernet 0/1)

2. Router interface to module (Integrated Service Engine 1/0)

3. Module interface to router (eth0)

4. Module interface to external link (eth1)

Figure 3. ISR / AXP Interfaces

Configuring an IP Unnumbered Interface

The router interface to an external link (labeled 1 in Figure 3) can be configured with an IP address, as follows:
2800_w_AXP# show running-config <enter>
....
interface GigabitEthernet0/1
ip address 192.168.1.1 255.255.255.0
...
In the IP Unnumbered scenario, it is possible to enable IP on the Integrated Service Engine 1/0 interface (labeled 2 in Figure 3) and bring it up without assigning a unique IP address to it. This is accomplished as follows:
2800_w_AXP# show running-config <enter>
....
!
interface Integrated-Service-Engine1/0
ip address unnumbered GigabitEthernet 0/1
service-module ip address 192.168.1.2 255.255.255.0
service-module ip default-gateway 192.168.1.1 (this is the IP address of GigabitEthernet 0/1)
no keepalive
no mop enabled
!
....
Use of the ip unnumbered command results in the IP address being shared by two interfaces. Thus, in our example, the IP address that was configured on the GigabitEthernet 0/1 interface is also assigned to the Integrated-Service-Engine 1/0 interface, where both interfaces function normally. This can be verified using the output of the show ip interface brief command, as follows:
2800_w_AXP# show ip interface brief <enter>
Interface IP-Address OK? Method Status Protocol
Gigabit Ethernet0/1 192.168.1.1 YES NVRAM up up
In1/0 192.168.1.1 YES TFTP up up
As you can see from the output of the command, the integrated service engine's interface (In1/0) has an IP address identical to that of the Ethernet interface, and both interfaces are fully functional. The interface that borrows its address from one of the router's other functional interfaces is called the "unnumbered interface." In our example, integrated service engine 1/0 is the unnumbered interface.

Note: An unnumbered interface is unavailable for remote testing and management. Also, if the unnumbered interface is pointing to an interface that is not functional (that is, one that does not show "Interface status UP," "Protocol UP"), the unnumbered interface is not available either. An acceptable remedy to this issue is to configure the unnumbered interface to point to a loopback interface, since loopbacks do not fail.

One IP Address for One or More Applications

In this scenario, an application is configured to bind to a single interface (eth0), using a single IP address for all IP traffic to and from the application. It is the responsibility of the application to manage port-based flows in this case. (This becomes more of a concern if multiple applications are loaded in separate vserver instances and bind to the same IP interface.) If multiple applications are going to be running on a single AXP module, it is recommended that multiple subinterfaces be configured, at a minimum (see "Multiple IP Addresses for One or More Applications"), and ideally multiple subnets (see "Multiple IP Subnets for One or More Applications"). Figure 4 shows an example configuration.

Figure 4. Example of Configuring One IP Address for One or More Applications

ISR Side of Integrated Service Engine

The ISR is, in effect, providing power and packet forwarding services to the AXP blade over the aforementioned internal Ethernet interface. This interface is seen when the show running-config command is executed from the ISR command prompt, as seen here:
2800_w_AXP# show running-config <enter>
....
!
interface Integrated-Service-Engine1/0
ip address 192.168.2.1 255.255.255.0
service-module ip address 192.168.2.2 255.255.255.0
service-module ip default-gateway 192.168.2.1
no keepalive
no mop enabled
!
....
Compare the IP addresses given in this example to the relationship between the ISR side and the AXP side of the Gigabit Ethernet interface in Figure 4. Notice how the configuration line items on the AXP side are preceded with service-module. We can see this by sessioning into the AXP module and looking at the running-config there.

AXP Side of the Integrated Services Engine

This section assumes that you are sessioned into the AXP module from the ISR. The service-module ip address 192.168.2.2 255.255.255.0 configuration line item in the ISR show running-config command shows up in the AXP show running-config command, except from the AXP module's perspective (eth0), as shown here:
AXP-2800# show running-config <enter>
....
interface eth0
ip address 192.168.2.2 255.255.255.0
exit
....

Binding the Application(s) to the IP Interface

Binding an application to a specific interface occurs while sessioned into the AXP module. An administrator has the ability to bind an application to any available Ethernet interface shown in the show running-config command (executed from the AXP context), whether it's a standard interface or a subinterface. This section describes binding to a single available interface (eth0), as shown here:
....
app-service my-application
bind interface eth0
hostname AXP-2800
exit
....

Multiple IP Addresses for One or More Applications

This section describes a scenario in which one or more applications on the AXP module require more than one IP address. On the AXP module, the administrator must configure subinterfaces, assign unique IP addresses to each, and then bind each interface to whichever applications need to use the corresponding IP address assigned to that interface. This allows multiple applications to send and receive data packets and create unique sockets without having to worry about Layer 4 port overlap between applications. Figure 5 shows an example configuration.
This section assumes that the applications all reside on the same subnet. If multiple subnets are required in support of the application(s), refer to the next section, "Multiple IP Subnets for One or More Applications."

Figure 5. Example of Configuring Multiple IP Addresses for One or More Applications

ISR Side of Integrated Services Engine

The ISR is, in effect, providing power and packet forwarding services to the AXP blade over the aforementioned internal Ethernet interface. This interface is seen when the show running-config command is executed from the ISR command prompt, as seen here:
2800_w_AXP# show running-config <enter>
....
!
interface Integrated-Service-Engine1/0
ip address 192.168.2.1 255.255.255.0
service-module ip address 192.168.2.2 255.255.255.0
service-module ip default-gateway 192.168.2.1
no keepalive
no mop enabled
!
....

Note: This is the same ISR configuration as seen in the previous example.

Compare the IP addresses given in this example to the relationship between the ISR side and the AXP side of the Gigabit Ethernet interface in Figure 5. Notice how the configuration line items on the AXP side are preceded with service-module. We can see this by sessioning into the AXP module and looking at the running-config there.

AXP Side of the Integrated Services Engine

This section assumes that you are sessioned into the AXP module from the ISR. The service-module ip address 192.168.2.2 255.255.255.0 configuration line item in the ISR show running-config command shows up in the AXP show running-config command, except from the AXP module's perspective (eth0), as shown here:
AXP-2800# show running-config <enter>
....
interface eth0
ip address 192.168.2.2 255.255.255.0
exit
interface eth0:1
ip address 192.168.2.3 255.255.255.0
exit
interface eth0:2
ip address 192.168.2.4 255.255.255.0
exit
....

Binding the Application(s) to the IP Interfaces

Binding an application to a specific interface occurs while sessioned into the AXP module. An administrator has the ability to bind an application to any available Ethernet interface shown in the show running-config command (executed from the AXP context), whether it's a standard interface or a subinterface. This section describes binding each application vserver instance to its own subinterface (my-application --> eth0:1, my_other_application --> eth0:2), as shown here:
....
app-service my_application
bind interface eth0:1
hostname AXP-2800
exit
app-service my_other_application
bind interface eth0:2
hostname AXP-2800
exit
....

Multiple IP Subnets for One or More Applications

This section describes a scenario in which one or more applications on the AXP module require more than one IP subnet, for separation. On both the ISR (Cisco IOS® Software) and the AXP module, the administrator must configure subinterfaces in a corresponding manner so as to create a 1-to-1 relationship across the Gigabit Ethernet connection. The administrator must assign unique IP addresses to each interface in different subnets, enable 802.1Q VLAN trunking across the link, and then bind each interface to whichever applications need to use the corresponding IP address assigned to that interface. This allows multiple applications to send and receive data packets on unique subnets, offering Layer 3 separation. Figure 6 shows an example configuration.
This section assumes that the applications all reside on different subnets. If only a single subnet is desired, see the previous section, "Multiple IP Addresses for One or More Applications."

Figure 6. Example of Configuring Multiple IP Subnets for One or More Applications

Note: In this scenario, the application developer must ensure that the packets placed on the network include the source IP address of the interface the application vserver is bound to. This is an explicit force function that is typically accomplished by passing the source IP address to the socket_open method. For example, the ping utility will take the -I switch to force ping packets to place the interface IP address in the packet header as follows: ping -I 192.168.100.2 192.168.1.1.

ISR Side of Integrated Service Engine

The ISR is, in effect, providing power and packet forwarding services to the AXP blade over the aforementioned internal Gigabit Ethernet interface. The subinterfaces (ISE1/0.1 and ISE1/0.2) are seen when the show running-config command is executed from the ISR command prompt, as seen here:
2800_w_AXP# show running-config <enter>
....
!
interface Integrated-Service-Engine1/0
ip address 192.168.2.1 255.255.255.0
service-module ip address 192.168.2.2 255.255.255.0
service-module ip default-gateway 192.168.2.1
no keepalive
!
interface Integrated-Service-Engine1/0.1
encapsulation dot1Q 100
ip address 192.168.100.1 255.255.255.0
!
interface Integrated-Service-Engine1/0.2
encapsulation dot1Q 200
ip address 192.168.200.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.1.1
!
....
Compare the IP addresses and the 802.1Q VLAN assignments given in this example to the relationship between the ISR side and the AXP side of the Gigabit Ethernet interface in Figure 6. We can see the relationship across the VLAN trunk by sessioning into the AXP module and looking at the running-config there.

AXP Side of the Integrated Service Engine

This section assumes that you are sessioned into the AXP module from the ISR. The service-module ip address 192.168.2.2 255.255.255.0 configuration line item in the ISR show running-config command shows up in the AXP show running-config command, except from the AXP module's perspective (eth0). The administrator must create VLAN trunk interfaces eth0.100 and eth0.200 and give them valid IP addresses corresponding to those assigned on the ISR side of the Gigabit Ethernet connection.
The administrator must also configure source-based routing so that traffic originating from a specific vserver instance is forwarded to the appropriate ISR-side interface. Only related running-config line items are shown here:
AXP-2800# show running-config <enter>
....
ip access-list standard 10
permit 192.168.100.2
exit
ip access-list standard 20
permit 192.168.200.2
exit
....
interface eth0
ip address 192.168.2.2 255.255.255.0
exit
interface eth0.100
ip address 192.168.100.2 255.255.255.0
ip route table 10
exit
interface eth0.200
ip address 192.168.200.2 255.255.255.0
ip route table 20
exit
interface eth1
exit
no ip ssh server
ip route table 10 0.0.0.0 0.0.0.0 192.168.100.1
ip route table 20 0.0.0.0 0.0.0.0 192.168.200.1
route-map CLASSIFY 10
match ip address 10
set route table 10
exit
route-map CLASSIFY 20
match ip address 20
set route table 20
exit
ip local policy route-map CLASSIFY
app-service my_application
bind interface eth0.100
hostname AXP-3800
exit
app-service my_other_application
bind interface eth0.200
hostname AXP-3800
ip ssh server
exit
....

Binding the Application(s) to the IP Interfaces

Binding an application to a specific interface occurs while sessioned into the AXP module. An administrator has the ability to bind an application to any available Ethernet interface shown in the show running-config command (executed from the AXP context), whether it's a standard interface or a subinterface. This section describes binding each application vserver instance to its own subinterface (my-application --> eth0.100, my_other_application --> eth0.200), as shown here:
AXP-2800# show running-config <enter>
....
app-service my_application
bind interface eth0.100
hostname AXP-2800
exit
app-service my_other_application
bind interface eth0.200
hostname AXP-2800
exit
....

External Gigabit Ethernet Interface

On the NME versions of the AXP module, there is an external Gigabit Ethernet port that can be used to access a separate network segment. Figure 7 shows an example configuration. Some applications may choose to use this interface exclusively, and some may use it in addition to the internal Gigabit Ethernet interface discussed in detail earlier in this document. In any case, this external Gigabit Ethernet interface, when configured, becomes just another interface for vserver instances to potentially bind to.

Figure 7. External Gigabit Ethernet Connection

ISR Side of Integrated Service Engine

The ISR is, in effect, providing power and packet forwarding services to the AXP blade over the aforementioned internal Gigabit Ethernet interface. The external Gigabit Ethernet interface is configured solely from the AXP context and therefore no corresponding ISR Cisco IOS Software configuration is required. For initial setup and sessioning into the blade from the ISR, the minimum Cisco IOS configuration on ISE1/0 is required, as shown here:
2800_w_AXP# show running-config <enter>
....
!
interface Integrated-Service-Engine1/0
ip address 192.168.2.1 255.255.255.0
service-module ip address 192.168.2.2 255.255.255.0
service-module ip default-gateway 192.168.2.1
no keepalive
no mop enabled
!
....

AXP Side of the Integrated Service Engine

This section assumes that you are sessioned into the AXP module from the ISR. The service-module ip address 192.168.2.2 255.255.255.0 configuration line item in the ISR show running-config command shows up in the AXP show running-config command, except from the AXP module's perspective (eth0). The administrator must configure the external Gigabit Ethernet interface from the AXP command-line interface (CLI), as shown here:
AXP-2800# show running-config <enter>
....
interface eth1
ip address 192.168.25.1 255.255.255.0
exit
....

Binding the Application(s) to the IP Interfaces

Binding an application to a specific interface occurs while sessioned into the AXP module. An administrator has the ability to bind an application to any available Ethernet interface shown in the show running-config command (executed from the AXP context), whether it's a standard interface or a subinterface. This section describes binding each application vserver instance to the external Gigabit Ethernet interface (eth1), as shown here:
AXP-2800# show running-config <enter>
....
app-service my_application
bind interface eth1
hostname AXP-2800
exit
....

Packet Services

There are alternative ways of forwarding packets to the AXP service module other than traditional IP routing. With traditional IP routing, packets entering the ISR will be forwarded to an AXP IP interface using the forwarding information base (FIB) and the routing engine. This methodology, known as direct mode, works well for applications requiring client-server type interactivity (such as Web Server on AXP).
However, there are applications that require promiscuous methods, in which select IP packets are first replicated in Cisco IOS Software and only a copy is forwarded to the AXP service module. The original packets follow traditional IP routing and are forwarded as if untouched. This second methodology, known as promiscuous mode, is accomplished using one of two available technologies, Cisco Network Analysis Module (NAM) Packet Capture or Router IP Traffic Export (RITE), and is commonly used for passive-type applications (such as Sniffer on AXP).
This section describes the two available promiscuous mode technologies, including their benefits and limitations, and illustrates example configurations. There are also more complex forwarding methodologies that can be configured that support AXP high-availability architectures. See the AXP High Availability Application Note for details: <link to that doc here>.

NAM Packet Capture

Note: The currently shipping AIM hardware version does not support the NAM Packet Capture feature and therefore cannot be configured as described below. The NME hardware versions do support this feature.
Cisco IOS Software enables a configuration to duplicate packets for network analysis when it detects the presence of the Network Analysis Module (NAM) physically attached to the ISR.

Advantages

• Easy to configure

• Exports both inbound and outbound traffic on the configured interface

• Exports locally generated packets (router-generated)

Limitations

• Exports all traffic or nothing-no support for access control lists (ACLs) or sampling

• Exports only to an attached AXP (or NAM, IDS) module

• Cannot specify which interface to export when there are multiple choices (for example, if the AXP supports vlans)

• Behavior when multiple AXPs are present is unclear

Sample Configuration

Configure analysis-module monitoring under the monitored interface. Traffic will be duplicated and exported to the AXP.
AXP-2800# show running-config <enter>
....
interface GigabitEthernet0/0 (this is the ISR interface where packets of interest enter the router)
ip address 1.100.50.221 255.255.255.0
duplex auto
speed auto
analysis-module monitoring (this is the primary CLI command configured in Cisco IOS Software)
no keepalive
end
....

RITE

RITE is a lightweight mechanism for duplicating and exporting monitored traffic on an interface to an analysis module (AXP in this case). The AXP interface (Integrated-Service-Engine x/y) behaves like an Ethernet interface and is therefore a supported export interface for RITE.
RITE provides a more granular traffic capture over NAM. One can specify ACL, sampling rate, and also the direction of the capture to export more specific traffic on an interface. There is, however, one noteworthy limitation with RITE: it will not capture router-generated traffic. These router-generated packets are process switched and not Cisco Express Forwarding switched, and they are therefore not along the capture path of RITE.

Advantages

• Can capture incoming or bidirectional traffic

• User specifies the export interface

• Supports ACL filtering and sampling of traffic

• Two monitored interfaces can have two different export interfaces

• Export interface can be a vlan

Limitations

• Router-generated packets cannot be exported

• One export interface per profile

• One profile per monitored interface

Sample Configuration

The high-level steps to configure RITE are:

1. Create a RITE capture profile

2. Configure the parameters of the profile

3. Apply the profile on the interface one wishes to monitor

Create a RITE Capture Profile

• Create a profile with ip traffic-export profile [any name].

• Configure the interface you wish to export to. This should be interface Integrated-Service-Engine 1/0.

• Configure the MAC address of the Integrated-Service-Engine1/0 interface with the mac-address [address] command.

• One can optionally configure bidirectional if one wishes to capture both inbound and outbound traffic. Inbound-only capture is the default.

Note: The service module is set to route packets by default. Configuring a valid MAC address will cause the routing stack of the service module to route the traffic, which is not a desired behavior in promiscuous mode (this will cause duplicated packets to be routed). To eliminate this problem, it is recommended that you configure an invalid MAC address (something other than the MAC address of the service module, such as a.a.a). This way your traffic will reach the service module but will not be routed.

Example Configuration

2800_w_AXP(config)# ip traffic-export profile rite-bi <enter>
2800_w_AXP (conf-rite)# ? <enter> (IP traffic export profile configuration commands)
bidirectional Enable bidirectional traffic export
exit Exit from IP traffic export profile sub mode
incoming Configure incoming IP traffic export
interface Specify outgoing interface for exporting traffic
mac-address Specify Ethernet address of destination host
no Negate or set default values of a command
outgoing Configure outgoing IP traffic export
AXP-2800# show running-config <enter>
....
ip traffic-export profile rite-bi
interface Integrated-Service-Engine1/0
bidirectional
mac-address a.a.a
....

Configure RITE Export Parameters

One can configure incoming or outgoing parameters by entering each menu. You can apply a regular access-list or configure the sample rate of the export traffic.

Example:

2800_w_AXP (config)# ip traffic-export profile rite-bi <enter>
2800_w_AXP (conf-rite)# incoming ? <enter> (commands for configuring incoming filter)
access-list Apply standard or extended access lists to exported traffic
sample Enable sampling of exported traffic
AXP-2800# show running-config <enter>
....
ip traffic-export profile rite-bi
interface Integrated-Service-Engine1/0
bidirectional
incoming access-list 4
outgoing access-list 4
mac-address a.a.a
incoming sample one-in-every 2
outgoing sample one-in-every 2
....

Apply the Profile to an Interface

Configure ip traffic-export apply [profile name] on the interface you wish to monitor.

Example:

AXP-2800# show running-config <enter>
....
interface GigabitEthernet0/0
description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$
ip address 1.100.50.221 255.255.255.0
ip traffic-export apply rite-bi
duplex auto
speed auto
no keepalive
end
....

Comparison of NAM Packet Capture and. RITE Features

Table 1 compares the features of NAM Packet Capture and RITE

Table 1. Comparison of NAM Packet Capture and RITE

 

NAM Packet Capture

RITE

Traffic monitored

Inbound/Outbound + router

Inbound/Outbound

Traffic filter

All or nothing

Access list control

Traffic sampling

None

Can sample one in every N packets.

Ease of use

Easy configuration

Create capture profile, then apply on interface

Define export interface

No

Yes

Summary

Cisco has provided a very flexible environment for applications to reside inside of an ISR. Deployment scenarios may range from very simple (one common internal Gigabit Ethernet interface) to significantly more complex (multiple subinterfaces, multiple IP subnets, multiple vserver instances). Much of the configuration required is typical to standard Cisco IOS Software CLI functionality, which makes configurations relatively easy to complete.
Packet forwarding is another key element in configuring applications on the AXP service module. Depending on the type of application behavior, different packet services are also configurable (for example, direct versus promiscuous modes).