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:
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 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:
For our examples, the following will be used:
COOKBOOK_ROUTER_STANDALONE
COOKBOOK_ROUTER_HA
COOKBOOK_ROUTER_DVR
You will need the following details, at a minimum, for networks attached to the router:
For our example, the following will be used:
COOKBOOK_PROVIDER_NET
COOKBOOK_TENANT_SUBNET
With the openstack
client installed on our system, we are now able to create a router with the following steps:
openstack router create COOKBOOK_ROUTER_STANDALONE
The output will resemble the following:
openstack router create COOKBOOK_ROUTER_HA --ha
The output will resemble the following:
openstack router create COOKBOOK_ROUTER_DVR --distributed
The 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.
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.
18.219.220.22