- Overview
- Guides
- Getting Cat9K Setup
- Docker Applications Development
- ThousandEyes Application Hosting
- Getting started with Docker Applications Deployment
- Application Hosting Configuration
- Build Docker applications Using Docker Toolchain
- Open Source Application Deployment
- Cisco ASAc Application Deployment
- Third Party Application Deployment
- Learn More
- Developer Resources
- Community and Support
Application States
Application Hosting framework provides a consistent mechanism for application lifecycle management.
An application residing on Catalyst 9000, will be in any of the following states:
- DEPLOYED: Application is installed on the device. Resources needed by the application is not committed to the application.
- ACTIVATED: The resources required by the application is now committed. Associated container artifacts are also generated.
- RUNNING: Application is now running.
- STOPPED: Application is stopped.
The below state diagram summarizes various actions that can be performed on an application and transition rules.
What is Activation and Deactivation?
Applications asks are described through configuration CLI. At development time, a developer will only be able to articulate such requirements. However, how those requirements are made available to the application can only be decided at deployment time by the administrator.
Further, the administrator may need to change the resource provisioning. For instance, the app may need to be scaled up by granting more cpu/memory resources.
In order to facilitate the ability to generically state requirements but enable the association or provisioning of those requirements at a later point in time, the activation concept is introduced.
After deployment, the application is available on the device. The administrator can then provision the right resources during activation time at which point the resources are committed to the application. If the resource allocation or mapping needs to change, the administrator can DEACTIVATE and ACTIVATE again with the updated mapping without having to uninstall and reinstall the application again.
Application Resource Limit
| Platform | Memory (GB) | vCPUs | CPU Units | USB Back Storage (GB) | M2 SATA Storage (GB) |
|---|---|---|---|---|---|
| Catalyst 9300 | 2 | 2 | 7400 | 120 | NA |
| Catalyst 9400 | 4-10 | 2 | 7400 | NA | 960 |
| Catalyst 9500 | 8 | 2 | 7400 | 120 | NA |
| Catalyst 9500 High-performance | 8 | 2 | 7400 | NA | 960 |
- vCPUs are maximum number of virtual CPUs that a single app can concurrently utilize.
- CPU Units represents the total CPU load resource allocated to Application Hosting. Each app specifies their guaranteed minimum CPU load required to keep the app running reliably.
- USB Back Storage : Refers to the Back-Panel recessed USB3.0 slot, Application Hosting only works on the back-panel USB3.0
- M2 SATA Storage : Refers to an internal SSD
- NA : Not Applicable
NOTE: Back-panel USB Flash and SATA HDD require EXT4 format for the best, reliable performance. However, if required, EXT2 is supported.
Networking in Details
Below highlights all the possible network modes the Cat9k support for app-hosting. They include:
- Front Panel Data port switching using the dedicated, internal AppGigabitEthernet interface
- Management Interface
Cat9k Networking
What is AppGigabitEthernet Interface?
AppGigabitEthernet is an internal hardware data port which is hardware switched to the front panel data ports.
Below diagram details the Application Hosting features supported for internal, dedicated AppGigabitEthernet Interface which connects the Applications to the HW switch fabric connected to the front panel data ports. Some features/restrictions:
- Container is L2 bridged to Front Data ports through the dedicated AppGigabitEthernet interface that is configured on IOS.
- The AppGigabitEthernet interface supports the same features as the cat9k's front-panel GigabitEthernet ports, specifically :
- switchport mode trunk
- switchport trunk allowed vlan
- Containers do have L3 routed access to an IOS SVI using app-vnic "trunk" mode. This is illustrated in the diagram with Container D's eth1 app-hosting network configs for VLAN 30 access that switches to "SVI vlan 30".
NOTE:
- "switchport mode access" should not be used since it limits the containers access to a single VLAN.
Cat9K AppGigabitEthernet Interface
In the example above, the Container network connectivity shown are:
- Container B's configuration allows the front-panel Ge0/0/1 (VLAN 10), Ge0/0/2 (VLAN 20), and Ge0/0/3 (VLAN 30) trunk traffic to be accessed by Container B's eth0 main interface. Container B is configured using app-hosting "app-vnic AppGigabitEthernet trunk" to send/receive "all" switch trunk vlans, including native, untagged frames, on Container B's eth0 main interface. Container B eth0 sub-if vlan 10 (eth0.10) and vlan 30 (eth0.30) configuration defines the different vlan traffic streams which the App sends/receives. These internal App linux sub-interfaces encap/decap the vlan tags. Since Container B does not define a sub-if eth0.20 for vlan 20, any received vlan 20 traffic is dropped by the App.
IOS interface AppGigabitEthernet configuration determines if "all" vlans are accessible via "switchport mode trunk" or restricted to certain vlans defined by "switchport trunk allowed vlan
Below shows the required IOS Container B configurations.
- Container C's configuration allows the front-panel Ge0/0/1 (VLAN 10) traffic to be accessed by Container C's eth0 main interface. Container C is configured using app-hosting "app-vnic AppGigabitEthernet trunk" for vlan 10 to send/receive only untagged switch vlan 10 traffic on Container C's eth0 main interface. The internal Linux Bridge provides the VLAN 10 decap/encap feature for the App's eth0 native, untagged traffic.
IOS interface AppGigabitEthernet trunk mode configuration determines which vlans the container has access to. Since Container C needs vlan 10, minimally vlan 10 must be allowed by interface AppGigabitEthernet.
Below shows the required IOS Container C configurations.
- Container D illustrates any number of App's interfaces can be defined and connected to the allowed AppGigabitEthernet vlans. This use-case has D's eth0 connected to the untagged vlan 20 traffic via app-hosting "app-vnic AppGigabitEthernet trunk" for vlan 20, while eth1 has access to untagged vlan 30 similarly using via app-hosting "app-vnic AppGigabitEthernet trunk" for vlan 30. These configurations allow Container D access to the front panel ports Ge0/0/2 (VLAN 20) and Ge0/0/3 (VLAN 30).
Below shows the required IOS Container D configurations.
Management Interface
Below diagram details the app-hosting features supported for Management Interface. Some features/restrictions:
- Container is L2 bridged to Management I/F.
- Must be on the same subnet as Management I/F. (Example below for subnet 172.19.0.0/24 : IOSd mgmt-if 172.19.0.1; Container 172.19.0.10)
- "Ge0/0" is the physical Management I/F port.
- All Cat9k platforms support Management Interface connectivity.
Cat9K Management Interface
Below are sample configurations connecting Container_A to the Management interface port. Static IP 172.19.0.10/24 is configured for the container app.
Note: only one Management interface can be connected to a given app.
Mixed Mode for Multiple Apps
For a specific app, only trunk or vlan-access mode can be configured. IOS-XE 16.12 CLI configuration prevents mixing the two modes for a specific app. This restriction will be removed in IOS-XE 17.1.
However, for multiple Apps, both trunk and vlan-access configs can coexist for the following AppGigabitEthernet modes :
- switchport mode trunk
- switchport trunk allowed
Below are some sample configurations of such mixed modes for multiple Apps using the same AppGigabitEthernet interface.
Summary of IOS Network Configurations
Below summarizes the supported Application Hosting network configurations supported for IOS-XE 16.12. Additional modes, such as L3 routing, will be supported in future IOS-XE releases.
