To update a routing table in the Azure network, you must first authenticate the Cisco Catalyst 8000V router. This is accomplished by creating an application which represents the Cisco Catalyst 8000V router in the Azure Active Directory. You can use the application that is granted permissions, to access the Azure network resources.

You can create the application by using the following two mechanisms:

• System-assigned managed identity - Azure automatically creates an application and binds it to the router. This mechanism was previously called as Managed Service Identity by Azure.

• Manual application registration in Azure Active Directory - Here, the user creates an application in the Azure Active Directory, which represents the Cisco Catalyst 8000V router.

You can manually create a managed identity in Azure Active Directory by creating an application which represents the router. The application is assigned a set of identifiers; tenant ID, application ID, and application key. These application identifiers must be configured in the high availability feature either as the default AAD application or within an individual redundancy node.

Alternatively, when you create the Cisco Catalyst 8000V, you can configure Azure to create a system-assigned managed identity for the Cisco Catalyst 8000V instance. In this case, you need not configure any application identifiers in the high availability feature. That is, in the absence of the configuration of an application’s tenant ID, application ID, and application key, the high availability feature assumes that the Cisco Catalyst 8000V router is using a system-assigned managed identity.

When you create the Cisco Catalyst 8000V router, you can enable for it to be assigned a system managed identity by Azure. There are two ways in which you can create a Cisco Catalyst 8000V router from the Azure marketplace:

• Solution template – A Cisco Catalyst 8000V router is created along with other Azure resources to create a networking solution in a single step.

• Standalone – A standalone Cisco Catalyst 8000V is created, usually within an existing virtual network, with the base Cisco Catalyst 8000V image.

If you create a Cisco Catalyst 8000V router by using one of the solution template offerings in the Azure marketplace, a system-assigned managed identify for the Cisco Catalyst 8000V is enabled by default. If you create a standalone Cisco Catalyst 8000V by using a base Cisco Catalyst 8000V image, a system-managed identity is enabled as shown in the following image:

There are a set of utility scripts that can be run in the guestshell environment to manage applications in the Azure Active Directory, whether they were created manually as user-assigned identities or system-assigned identities. The following sections describe the use of these scripts and how to configure the binding between a redundancy node and the application used to authenticate the Cisco Catalyst 8000V router.

• Managing user-defined applications: If you have chosen to use a user-assigned identity for the Cisco Catalyst 8000V router, the application that was created in Azure Active Directory must be configured in the high availability feature. The application can be configured as the default application used for all the redundancy nodes, or for individual redundancy nodes.

• Set the default application: If you configure a user-assigned application as the default application using the set_default_aad_app script, all the redundancy nodes use the specified application for authentication, unless a redundancy node has an individual application configured.

[guestshell@guestshell]$ set_default_aad_app.py -p azure -d c4426c0b-036f-4bfb-b2d4-5c910c5389d6 -a 3d6e2ef4-8160-4092-911d-53c8f68ba808 -k hZFvMGfzJuwFiukez27e/duyztom1bj7QL0Yix+KY9c=

[guestshell@guestshell]$ set_default_aad_app.py -h
usage: set_default_aad_app.py [-h] -p {azure,azusgov,azchina} -a A -d D -k K
AAD Application
required arguments:
  -p {azure,azusgov,azchina}	<cloud_provider> {azure | azusgov | azchina}
  -a A                  		to add the applicationId
  -d D                  		to add the tenantId
  -k K                  		to add the applicationKey

You can clear the default user-assigned application configuration by using the clear_default_aad_app script.

[guestshell@guestshell]$ clear_default_aad_app.py

If you create a user-assigned application and associate the application with individual redundancy nodes, information about these applications is cached in memory. You can display the list of known applications by using the show_auth_applications.py script. Clear the cache using the clear_aad_application_list script.

[guestshell@guestshell]$ clear_aad_application_list.py

Use the following scripts to manage all the applications - user-assigned or system-assigned.

[guestshell@guestshell]$ show_auth_applications.py

[guestshell@guestshell]$ clear_token.py

[guestshell@guestshell]$ refresh_token.py

The route tables in Microsoft Azure support different entry types. The entry type for a route can be one of the following: Virtual network gateway, Internet, or Virtual Appliance. The next hop address identifies a resource in the Azure network.

Routes with an entry type of Virtual network gateway or Internet do not have an explicit IP address for the next hop and are not supported by the High Availability feature.

When you configure High Availability on a Cisco Catalyst 8000V instance, you can specify individual routes to be updated in the case of failure. Ensure that you configure each individual route as having an entry type of Virtual Appliance. If you configure a redundancy node that represents all the entries in the route table, ensure that all the routes have an entry type of Virtual Appliance.

If you have a network security group attached to NIC0 of the router, you must allow the BFD protocol to pass the interface. Configure an inbound and outbound security rule that allows ports 4789 and 4790 to be passed.

Configuring the Console Timeout

When you start an SSH session to the Cisco Catalyst 8000V router, ensure that you do not configure the terminal VTY timeout as infinite. That is, do not configure: exec-timeout 0 0. Use a non-zero value for the timeout; for example, exec-timeout 4 0. This command specifies a timeout of four minutes and zero seconds. The exec-timeout 0 0 command causes an issue as Azure enforces a timeout for the console idle period of 4 to 30 minutes. When the idle timer expires, Azure disconnects the SSH session. However, the session is not cleared from the point of view of the Cisco Catalyst 8000V as the timeout was set to infinite (by the exec-timeout 0 0 configuration command). The disconnection causes a terminal session to be orphaned. The session in the Cisco Catalyst 8000V remains open indefinitely. If you try to establish a new SSH session, a new virtual terminal session is used. If this pattern continues, the maximum number of simultaneous terminal sessions allowed is reached and no new sessions can be established. In addition to configuring the exec-timeout command correctly, it is also a good practice to delete idle virtual terminal sessions using the commands that are shown in the following example:

RouterA# show users
Line User Host(s) Idle Location
2 vty 0 cisco idle 00:07:40 128.107.241.177
* 3 vty 1 cisco idle 00:00:00 128.107.241.177
RouterA# clear line 2

Note	If the workaround in the preceding scenarios are ineffective, as a last resort, you can restart the Cisco Catalyst 8000V router in the Azure portal.