Using concepts demonstrated in previous chapters, let's walk through the creation and decomposition of a highly available router. In the following example, I've started out with an external provider network named GATEWAY_NET and a project network named PROJECT_NET:

Using the openstack router create command with the --ha argument, we can create an HA router named MyHighlyAvailableRouter:

Upon creation of the HA router, a network namespace was created on up to three hosts running the Neutron L3 agent. In this demonstration, the L3 agent is running on the controller01 and two compute nodes.

In the following screenshot, a router namespace that corresponds to the MyHighlyAvailableRouter router can be observed on each host:

Neutron automatically created a network reserved for communication between the routers upon creation of the first HA router within a project using the network defined by the l3_ha_net_cidr configuration option in the L3 agent configuration file:

The HA network is not directly associated with the project and is not visible by anyone but an administrator, who is able to see all networks. The output here shows the details of the network:

As you can see, the project_id field is blank, while the name of the HA network includes the ID of the project. The network is used by Neutron for all HA routers created by that project in the future.

Both a gateway and internal interface have been attached to the router. The openstack port list command reveals the gateway, internal, and HA ports associated with the router:

The three HA ports were created automatically by Neutron and are used for communication between the router namespaces distributed across the hosts. Inside the network namespaces, we can find the corresponding interfaces:

In the preceding screenshots, the router namespace on  compute02 has been elected as the master router, as evidenced by the virtual IP, 169.254.0.1/24, being configured on the HA interface within the namespace. In addition to the HA interface, the qg and qr interfaces are only fully configured on the master router. If more than one router owns the virtual IP, or if you see the qg and qr interfaces fully configured on more than one router, there may be communication issues between the routers on the HA network.

You can use the openstack network agent list command with the --router and --long arguments to determine the agent(s) a router is scheduled to as well as see the HA state for the given agent, if applicable: