App Hosting Components on IOS XR

The following are the components of App Hosting:

• Docker on IOS XR: The Docker daemon is included with the IOS XR software on the base Linux OS. This inclusion provides native support for running applications inside Docker containers on IOS XR. Docker is the preferred method for running TPAs on IOS XR.

• Appmgr: While the Docker daemon comes packaged with IOS XR, Docker applications can only be managed using appmgr. Appmgr allows users to install applications packaged as RPMs and then manage their lifecycle using the IOS XR CLI and programmable models.

• PacketIO: This is the router infrastructure that implements the packet path between TPAs and IOS XR running on the same router. It enables TPAs to leverage XR forwarding for sending and receiving traffic.

TPA Security

IOS XR is equipped with inherent safeguards to prevent third party applications from interfering with its role as a Network OS.

• Although IOS XR doesn't impose a limit on the number of TPAs that can run concurrently, it does impose constraints on the resources allocated to the Docker daemon, based on the following parameters:

  • CPU: ¼ of the CPU per core available in the platform.

  • RAM: Maximum of 1GB.

  • Disk space is restricted by the partition size, which varies by platform and can be checked by executing "run df -h" and examining the size of the /misc/app_host or /var/lib/docker mounts.

• All traffic to and from the application is monitored by the XR control protection, LPTS.

• Signed Applications are supported on IOS XR. Users have the option to sign their own applications by onboarding an Owner Certificate (OC) through Ownership Voucher-based workflows as described in RFC 8366. Once an Owner Certificate is onboarded, users can sign applications with GPG keys based on the Owner Certificate, which can then be authenticated during the application installation process on the router.

The table below shows the various functions performed by appmgr.

Guidelines and Limitations

• For the options --mount and --volume, only the following values can be configured:

  • "/var/run/netns"

  • "/var/lib/docker"

  • "/misc/disk1"

  • "/disk0"

• The maximum allowed size for shm-size option is 64 Mb.

• Prior to Release 24.4.1, all container logs were recorded with an info severity level (sev-6), regardless of the docker run time options used. From Release 24.4.1, if the docker run time option -it is used, the container logs are generated with an info severity level (sev-6). However, if the --it option is not included, the logs are produced with an error severity level (sev-3).

• From Release 24.4.1, you can use the rsyslog daemon to forward syslog messages to remote syslog servers. To know more, see Support for logging functionality on third-party applications.

Configuration

This section provides the information on how to configure the docker run time options.

In this example we configure the docker run time option --pids-limit to limit the number of process IDs using appmgr.

Router#appmgr application alpine_app activate type docker source alpine docker-run-opts "-it –pids-limit 90" docker-run-cmd "sh"
Router# 

In this example we configure the docker run time option --pids-limit to limit the number of process IDs using Netconf.

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <edit-config>
    <target>
      <candidate/>
    </target>
    <config>
      <appmgr xmlns=http://cisco.com/ns/yang/Cisco-IOS-XR-um-appmgr-cfg>                     
        <applications>
          <application>
            <application-name>alpine_app</application-name>
            <activate>
              <type>docker</type>
                                             <source-name>alpine</source-name>
                                             <docker-run-cmd>/bin/sh</docker-run-cmd>
                                             <docker-run-opts>-it --pids-limit=90</docker-run-opts>
            </activate>
          </application>
        </applications>
      </appmgr>
    </config>
  </edit-config>

Verification

This example shows how to verify the docker run time option configuration.

Router# show running-config appmgr
Thu Mar 23 08:22:47.014 UTC
appmgr
 application alpine_app
  activate type docker source alpine docker-run-opts "-it –pids-limit 90" docker-run-cmd "sh"
 !
!

You can also use docker inspect container id to verify the docker run time option configuration.

Router# docker inspect 25f3c30eb424
[
    {
                  "PidsLimit": 90,
    }
]

Configuring Traffic Prioritization for TPA in a Sandbox

During the configuration of a TPA port, you can now set the priority for the port as High, Medium, or Low.

Configuring high priority traffic port

This example shows how to configure TPA traffic in port 2018 to high LPTS flow priority.

Router(config)# sandbox flow TPA-APPMGR-HIGH ports 2018

Configuring medium priority traffic port

This example shows how to configure TPA traffic in port 6666 to medium LPTS flow priority.

Router(config)# sandbox flow TPA-APPMGR-MEDIUM ports 6666

This example shows how to configure TPA traffic in port 60100 to low LPTS flow priority.

Router(config)# sandbox flow TPA-APPMGR-LOW ports 60100

Verification

This example shows how to verify TPA traffic prioritization.

Router(config)# show lpts pifib hardware police location

TPA-APPMGR-HIGH        103     np      NPU             1940      1000      0            0            0        
TPA-APPMGR-HIGH        103     np      NPU             1940      1000      1456         0            1        
TPA-APPMGR-MED         104     np      NPU             1940      1000      0            0            0        
TPA-APPMGR-MED         104     np      NPU             1940      1000      1455         0            1        
TPA-APPMGR-LOW         105     np      NPU             1940      1000      0            0            0        
TPA-APPMGR-LOW         105     np      NPU             1940      1000      1456         0            1 

Restrictions and Limitations

In configuring your setup, please consider the following restrictions and limitations:

• VRF Forwarding Limitation: The Virtual Routing and Forwarding (VRF) is only supported for Docker apps with host networking.

• Relay Agent Availability and Management: The relay agent container is designed to be highly available. It will be managed by the Application Manager (App Mgr).

• Relay Agent Creation: For each pair of forwarded ports, one relay agent container will be created.

• Port Limitation per Application: The total effective number of ports for each application is limited to a maximum of 10.