The Cisco Enterprise routing portfolio consists of multiple products targeted at different segments of the network. Even though these appear to be very different products at first glance, they all share a common architecture and operating system. Cisco IOS XE is the common architecture unifying the 4000 Series Integrated Services Routers, 1000 Series Aggregation Services Routers.
The Cisco ISR 4000 (ISR4K) Series platforms are multi-service branch platform that has superior performance to the second generation ISRs, while the ASR 1000s (ASR1K) can serve as hight performance WAN edge router or aggregation service routers for service providers as well as enterprise networks.
The IOX application hosting capabilities on these platforms further extends Cisco Fog Computing capbilites from small footprint routers such as the ISR 8xx and IR 8xx platforms to more powerful routers, The ISR4K and ASR1K can also host application based on the industry standard x86 CPU architecture. The familiar set of IOx management framework and tools can be used to manage application life cycle running on these platforms.
Please see the following page for more information:
Cisco 4000 Series Integrated Services Routers
Cisco ASR 1000 Series Aggregation Services Routers
The ASR1K and ISR4K are all intel based multi-core x86 CPU runing in 64bit SMP mode with hyper-thread support. Each platfrom has number of powerful CPU cores dedicated to support application hosting, refer to the "platform support" page.
The current release of IOx on ASR1K and ISR4K routers will support the IOx VM application. There is a minimum memory and storage requirments they are: 8GB RAM, 20GB SATA harddisk or SSD.
The application hosting architecture is show in the diagram below:
IOx Infra:

IOx enables application lifecycle to be managed externally, via Fog Director, Local Manager Webui and also the ioxclient. These entities communicate with the IOx CAF (Cisco Application Hosting Framework) component through a set of RESTapi to orchestrate application VM lifecycle in IOS-XE. On the IOS-XE platform external http/https traffic terminated in the router needs to pass through the NGNIX webserver hence IOx RESTapi traffic will need to be proxied through the webserver and it will share the same IP address as NGNINX.
Supported IOx Application Type
For this current release of IOX in IOS-XE, only IOx VM type application is supported. The IOx VM app will be created as KVM VM under the IOS-XE platform linux.
Networking Support

Setting up IOx netowrking involves 2 parts
Enabling IOx CAF communication
On IOS-XE all http/https traffic is front ended by an NGINX webserver. Therefore IOx RESTAPI and local manger WebUI traffic also go through NGINX. Also the NGINX server only connects through the management VRF therefore the management VRF needs to be configured and an external interface needs to be associated for external traffic to pass through. The purpose of the VRF is to segregate the management traffic from data traffic.
Enabling IOx application communication
IOX VM application virtual machines are connected to IOS routing domain via an internal network interface VirtualPortGroup (VPG), as depicted in the diagram above, VirtualPortGroup 1. Traffic to and from the IOx VM is routed through the switch and currently only supports IPv4. Up to four unique VPGs can be configured per application.
IOS images
The minimum IOS-XE version required for IOx support is (V163_1)
.
The IOx functionality, unlike in other platforms, are built into IOS-XE and cannot be installed separately.
Configuring Management Network
Since the CAF RESTAPI is font ended by the NGINX webserver in the IOS-XE router, reacheability of CAF requires configuring the management network of the router. The following configuration applies to the ISR4K series router.
1a) Set up the external interface IP address
1b) Set the default gateway and route for management network
At this point the router should be pingable from outside the box on the external interface IP
Enable IOx
2-) Enable IOS http server and configure application hosting
- Enable IOS-XE http server
- Enable installation of unsigned application using virtual-service
- Enable IOx application hosting
You have to do this no matter what scenario you are using for the box. At this point, provided the basic network is setup, you will be able to communicate with CAF.
- iox-client:
- "Your IOx platform's port number[8443] :" use "443"
- "Your IOx platform's SSH Port[2222]:" use "22"
- Local Manager: http://{GE0-ip-address}/webui/#/ioxmain
- Fog Director: For the "Device Add" option, configure {GE0-ip-address} and port 443
VirtualPortGroup configuration -Developer Mode
In this scenario:
- The router is not used for actual routing. It is at the edge of the network.
- This mode suits developers who just need the application to have access to the external network
- The Application sits behind a NAT. So, a DHCP pool assigning a local IP address is configured on IOS.
1-) We configure the VirtualPortGroup interface which talks to the applications as follows. Here the VirtualPortGroup (VPG) is sitting behind the NAT. Alternative VPG configuration is also possible and shown in the next section.
2-) We will configure a DHCP network pool on IOS from which application can get an IP address via DHCP
2a) Configure the DHCP pool for the network (in this case 192.168.1.0/24). We also set up the NTP servers here
2b) Exclude the addresses which you don't want to be assigned
2c) Configure ntp master as backup
Alternative VirtualPortGroup configuration - Stationary mode
In this scenario:
- The router is used for actual routing. It is at the middle of the network.
- This mode suits users who need the application to have access to and be accessible from the external network.
- The Application does not sit behind a NAT.
- The VirtualPortGroup borrows the external interface IP address. Now it can be reached from outside the router.
- The Application gets its interface IP from an external DHCP server by relaying the DHCP request through the VirtualPortGroup. It will also get an external IP address.
We configure the VirtualPortGroup interface which talks to the application. In this scenario, since the DHCP server is external, all we need to do is configure the VirtualPortGroup with an IP helper
Internal DHCP pool
Please refer to examples in previous sections