A router in OpenStack represents a virtual routing device that provides routing capabilities to directly connected networks. To provide end-to-end connectivity to a virtual machine, a router must be connected to an external provider network and the tenant network where the instance resides. Typically, routers are created and managed by individual projects. By default, external provider networks are shared and available for use by all projects. The following diagram represents an external provider network owned by the ADMIN project and utilized by three other projects:
Figure 4.2
In Figure 4.2, three projects have routers connected to an external provider network. The external provider network not only provides connectivity to the routers and the networks behind them, but also provides a network from which floating IPs can be derived. Floating IPs provide 1-to-1 address translations that allow external clients to connect directly to instances.
Routers in OpenStack can be created using the openstack router create command. By default, routers are considered internal and can route only between directly-connected tenant networks. An external router, on the other hand, is capable of routing to an external gateway and can provide network address translation (NAT) services to connected networks.
There are three types of routers that can be created in an OpenStack reference architecture:
- Standalone
- Highly-Available (HA)
- Distributed (DVR)
Standalone routers do not provide any level of resiliency, while highly available routers implement VRRP to provide redundancy should one or more Neutron nodes fail. Distributed virtual routers reside on compute nodes rather than on centralized network nodes, and provide higher performance than their counterparts for east/west traffic, or traffic between instances in different networks, since that traffic is forwarded between compute nodes without having to traverse a network node.
For non-admin users, the type of router that is created with the openstack router create command is determined automatically by settings defined in Neutron configuration files. Only users with administrator-level permissions can specify router types when creating routers.
You will need the following details, at a minimum, for the router:
- Router name
For our examples, the following will be used:
- Router name:
COOKBOOK_ROUTER_STANDALONE - Router name:
COOKBOOK_ROUTER_HA - Router name:
COOKBOOK_ROUTER_DVR
You will need the following details, at a minimum, for networks attached to the router:
- External provider network name or ID
- Tenant subnet name or ID
For our example, the following will be used:
- External provider network name:
COOKBOOK_PROVIDER_NET - Tenant subnet name:
COOKBOOK_TENANT_SUBNET
With the openstack client installed on our system, we are now able to create a router with the following steps:
- Create the standalone router:
openstack router create COOKBOOK_ROUTER_STANDALONEThe output will resemble the following:
- Create an HA router:
openstack router create COOKBOOK_ROUTER_HA --haThe output will resemble the following:
- Create a distributed router:
openstack router create COOKBOOK_ROUTER_DVR --distributedThe output will resemble the following:
When any router is created in OpenStack using the native routing services, a corresponding network namespace is created on one or more nodes running the neutron-l3-agent service. The namespace can be identified using the ip netns command shown here:
# ip netns list ... qrouter-058ea6a3-ca86-46f8-80c8-d63bbc195212 ...
A router namespace has a prefix of qrouter- and a suffix that corresponds to the router ID. In environments where distributed virtual routers are configured, other namespaces needed to facilitate proper networking may exist, such as the fip- and snat- namespaces.
By default, a non-admin user cannot specify the type of router being created. The router type is automatically determined by Neutron based on the layer 3 agent configuration file. The author recommends HA or distributed virtual routers, where possible, to limit the impact of failure for physical nodes hosting virtual routers.
Note
Cloud operators can modify Neutron configuration files to change default behaviors. The policy.json file used by the Neutron API service can be modified to allow users and roles to perform actions usually reserved for administrators. Refer to community documentation for guidelines and caveats related to modifications to the policy.json files.