Lab - iperf3 Docker Container
Build the iperf3 RPM
Install Docker on the Ubuntu server:
Install build-essential
Configure the LAN interface on the Ubuntu server:
Clone the xr-aggmgr-build git repo:
Create a directory called iperf3, and create a file called build.yaml
Edit the build.yaml file, and paste the following:
Pull the iperf3 container, and save it as iperf3.tar within the iperf3 build directory.
Move up one level, and build the app. If you see an error, see the note below.
For some reason, I had to edit the file appmgr_build and change :-7 to :-4 on line 756. Otherwise I got an error that the filename does not match the source name.
Transfer the RPM
On XR1, add the LAN interface:
On the Ubuntu node, transfer the file at ~/xr-appmgr-build/RPMS/x86_64/iperf3-3-eXR_7.3.1.x86_64.rpm to XR1 using scp.
Prompt
Run the iperf3 container in server mode on XR1, and perform an iperf test from the Ubuntu server as the client.
Answer
Explanation
App hosting on IOS-XR is exactly what it sounds like - it is a feature that allows you to run third-party linux apps directly on the IOS-XR hardware.
There are two variants of app-hosting on IOS-XR:
Native
Apps are hosted inside the same container that is running native IOS-XR apps - the XR control plane container. This gives the app direct access to the same namespace as the IOS-XR apps such as BGP, OSPF etc.
Due to this, the app has full access to all resources shared by internal IOS-XR processes, which is dangerous.
The app must be built with a special linux distro (Wind River Linux 7).
Container
The app can be developed using any linux distro.
Resources can be constrained.
The app runs in its own separate namespace, independent from internal IOS-XR processes.
You can use LXC (linux containers) or docker.
IOS-XR runs the control plane as a container itself using LXC. Native apps run directly in the same control plane container, giving them full access to the IOS-XR control plane. A separate container space is also created for third party apps, which is where docker/LXC containers run. This gives them complete separation from the IOS-XR control plane.
While it might seem that running native apps is not a good idea, they do have their use cases. For example, the xr-auditor app requires access to the running IOS-XR processes to be able to actually run the audit of the system. If the xr-auditor app was run as a separate docker container, it would not have access to actually perform the audit.
A major change to app-hosting for docker containers was introduced in 7.5.1. Previously, you could run docker containers directly from the bash terminal using docker commands. Now this is no longer possible. In fact, the docker process does not automatically start anymore in version 7.5.1+. The only way to deploy docker containers now is using the AppMgr.
The AppMgr allows you to deploy and manage docker containers directly from the IOS-XR CLI. It also handles automatically respawning a container during an RP failover or after a reload. The AppMgr has CLI commands and YANG APIs for all capabilities provided by the AppMgr, such as starting/stopping/killing containers.
Next, we configure the AppMgr to run the container. The syntax is:
The package name comes from the build.yaml file used when building the RPM package:
The docker-run-opts are the same options used when launching a container, such as:
The docker-run-cmds are commands that are ran on the container. For example, with iperf3 we can simply use “-s” to run in server mode, or “-c 1.1.1.1” to connect to a specific client.
Once the appmgr configuration is commited, the container will automatically start. We can check that it is running using show appmgr application-table
We should be able to run an iperf test to the XRv9000 from the Ubuntu server.
On the XRv9000, we can see the results as well by looking at the logs for the app:
The appmgr application exec command gives us the ability to manipulate the running container. The exec command runs the “docker exec” command. The copy command is used to copy files between the container and the XR filesystem.
For example, we can kill the container using appmgr application kill name iperf3
If we start the container back up using appmgr application start name iperf3, we can also see the CPU/memory resources the app is consuming.
A note on networking with the underlying bash system
By default, only mgmt routes and a default route are programmed into the routing table of the bash environment. The loopback0 interface is used as the source interface by default as well. Actually in my environment, I see no default or mgmt routes at all currently. Even with this, the iperf3 app is still working.
The reason the routing table is so sparely populated is that the IOS-XR control plane programs the FIB with routes, but not the separate bash environemnt.
You change the source address from the loopback0 to another interface by setting the TPA (third-party app) source address. The below example uses an XRv9K that has a Mgmt IP address in 10.200.10.0/24, and is in the default VRF.
Above, the default route points to fwdintf, which is a special interface that simply forwards to the IOS-XR RIB for routing.
A note on signed apps
As of 7.5.1, application hosting now requires that applications be signed in order to be installed and used. However, I can’t tell if this was really the case with my XRv9000. Either the RPM package actually doesn’t need to be signed, or using the tool to build the RPM package also signs the package.
Either way, we still need to know the workflow for signing apps. The steps to do app hosting on 7.5.1+ are now as follows:
The RPM is signed using a GPG key (Gnu Privacy Guard) and key package which uses the owner cert.
The owner cert is onboarded onto the hardware TAm (Trust Anchor module) and is used to validate app signatures
The TAm appears to be like a certificate store, but rooted in the hardware itself, not software
The key package is installed, and then the RPM package is installed.
The CLI, NETCONF, or gRPC can be used to onboard the artifacts such as the ownership voucher, owner cert (burned into TAm), the RPM GPG key package, and the app package RPM itself. SZTP can be used to onboard the owner cert and OV, plus SZTP can run a script that onboards the app and key packages.
You can also create what’s called a GISO (golden ISO) which contains the XR7 image but with the app RPMs and key packages already loaded. The owner cert and OV must still be onboarded outside the GISO (using SZTP or the CLI/API).
TPA Security
This says that IOS-XR restricts a third-party app to 1/4 CPU per core, 1G RAM, and limited disk based on the size of /misc/app_host.
Additionally, all packages are subjected to policing by LPTS.
This article says that “signed applications are supported,” not that they are required. The basic idea is that apps are signed by onboarding an OC (owner certificate) using ownership voucher workflows. Once the OC is generated, the apps can be signed with GPG keys.
Last updated
