This section describes having a High Availability (HA) redundancy application that runs on Cisco IOS XRv 9000 router, and you need to have a mechanism for the virtual router to switch over from the active router to the standby router in case of failure. So, if the routing goes down (for example, the router fails, it stops forwarding traffic) then you need to detect that failure, and then initiate a failover to the standby router so that the traffic that was coming into the active router can be diverted to the standby router.

The advantages are:

• Redundancy: For any type of signaling traffic, you must need a redundant gateway solution. The advantage of a redundancy solution is, if one router goes down, the other router continues to send the traffic. So that the drop of traffic is minor.

• Failover: With the failover, only the active router passes traffic while the other router waits in a standby state. If an active router fails, the standby router immediately becomes the active router with little or no delay.

Amazon Web Services (AWS) is a public cloud where you are running a virtual machine on top. Both the active and standby routers running on AWS are available in the same availability zone and they have the same subnet. As a result, both the routers can communicate with each other. You can then set up a system on AWS where this failover can be triggered.

For example, router A is active initially. So all the traffic flows through this active router and you activate or run the application on router A. Spin up the same application on standby router B. The application then uses the service layer API to interact with the BFD process and start the BFD session with the standby router.

Both the routers have the same primary IP address which is unique. Router A also has the secondary IP address initially.

Note	Typically, in AWS, the packets are handled by AWS directly. So, the routers do not detect that the same standby IP is configured.

So, when the traffic comes to the router A interface, the traffic destination typically goes through the secondary private IP here. That means only the router that has the secondary private IP configured on the AWS underlay, expects the traffic to come in. That is the router that has the secondary IP configured on the AWS underlay. Both the routers communicate using BFD.

And when this router A goes down or the BFD session goes down, then the session down event is sent to the application running on the router which detects the failover event, use AWS API to connect to AWS for shifting the secondary IP from the active router A to the standby router B. So, when the secondary IP is shifted from active to standby, then the traffic is diverted from the active router A to the standby router because the secondary IP is in the standby router B. So, the standby router B becomes the active router now.

Note	If the secondary IP is associated with one router, that is active, and the other one is standby.

To know more about the HA redundancy application and how it works, refer to the HA Solution document.

The section describes configuring the On-box docker container to enable HA application on Cisco IOS XRv 9000 router using IOS-XR Service-Layer API and AWS API. You must perform these tasks in sequence as listed.

Restrictions

• The HA redundancy application works only on AWS.

  HA application works only when the following functions are supported:

  • Application hosting: The functionality of application hosting allows you to run the application on AWS cloud. You can create your own container on IOS XR, and an application in a separate container. The applications can be developed using any Linux distribution. To know how the app hosting functionality works, see Application Hosting Configuration Guide for Cisco ASR 9000 Series Routers.

  • Service layer API: Service Layer API is a model-driven API over Google-defined remote procedure call (gRPC). It gives you a gRPC server running on the router. You can enable it using a CLI in XR and you can create a client of the service layer API.

    For this feature, we are using the on-box client as an application runs as a docker container on the same router and it communicate s with the gRPC server. The application uses the service layer API in XR to create a BFD session. As a result, the application can trigger the setup of the BFD session and then be able detect events when the BFD session goes down. To know how the service layer API works, see Use Service Layer API to Bring your Controller on Cisco IOS XR Router or Cisco IOS-XR Service Layer.

  • Application Manager: The functionality of application manager allows you to restart all the third-party applications automatically after a router reload or an RP switchover. This process ensures seamless functioning of the hosted applications. The Docker daemon service starts on the router only if you configure a third-party hosting application using the appmgr command. Such an on-demand service optimizes operating system resources such as CPU, memory power, and power.

• Hot Standby Router Protocol (HSRP) does not work on AWS.

The task also provides you the topics available in the High-Availability GitHub page for HA page. Refer this page to see the detailed configuration examples.

After creating the files per router, deploy your application on the router by performing the following actions:

1. Copy the RPM file, config.json file, and the host file to the hard disk of the router.

   Note	Use SCP command to transfer the rpm file, json file, host file to the hard disk on the router.

2. Run the appmanager command to install application RPM packages, and then move both the config.json and the host file from the router hard disk to the application-specific folder. It is to start up the application.

3. Apply CLI configuration to activate or launch the application.

   The CLI consists of the following:

   • BFD echo disable. It is to run BFD sessions on AWS.

   • Tpa vra default. It is to ensure that all your packets that are going out of the router to help the application establish a connection to AWS. AWS must know from where the packets come from.

   • gRPC details. It is to connect to the application.

   • Static IP address. It is used as a gateway to reach the metadata URL of AWS. It is the standard public cloud operational procedure.

   • Application manager config. It has the application name to activate it as a docker application, the source image, and the docker run option. This is to launch the docker container and start running the application.

See the Deploy App section in GitHub for more information.

Based on your requirement, you can now run any of the following xr-appmgr commands to verify the application details.

• Run the application info command to get the details on the application that is being run.

• Run the application stats command to view the statistical details of the application run.

  The output displays the following information:

  • CPU percentage

  • Memory use and its percentage

  • Network

  • PIDs

  • Blocks

• Running the application logs command

  • Run the Docker container logs command to view the details related to the standard output logs from the docker container. It displays all the processes that are running in the container.

    The output shows a supervisor process running and it runs two more processes:

    • Application process

    • Redis process which is a database.

    These two processes together constitute your application.

  • Run the Application specific logs command to view the Application manager EXEC and then docker EXEC commands.

    When you run this command, it tails on the log file which is inside the docker container. It shows the behaviour of the application. Running this command displays the application-specific logs and you can troubleshoot the details when failover happens. You can also copy the logs to any location on the router, as required.

• Run the Application CLI commands to view the application-specific json-based CLI running inside a docker container.

  When you run the show redundancy command, it displays all show commands that you can run specific to the application.