"Neutron" Tenant Networks vs. Provider Networks

OpenStack's neutron defines two main types of network--tenant networks and provider networks. OpenStack administrators must decide how their neutron network deployment strategy will use--tenant networks, provider networks, or some combination of both.

This section describes the unique challenges posed by the tenant network in a private cloud environment and provides an argument for why the shared provider network offers the best neutron network deployment strategy for the enterprise private cloud. This section also discusses the rationale behind network assertions.

In this article, I will specifically point out that in a private cloud environment, the tenant network is problematic, and the provider network (especially the shared provider network) may be more appropriate.

What ' s a tenant?

In a private cloud, tenants can map to specific business units, to specific multi-tier applications, and even to a single application layer. All tenants ultimately belong to a single organization. This contrasts sharply with the public cloud, where individual tenants typically represent different organizations.

What is tenant networks/provider networks?

The main difference between the tenant network and the provider network is who provides these services. The provider network is created by the OpenStack Administrator on behalf of the tenant and can be dedicated to a specific tenant, either by the tenant or shared by all tenants. On the other hand, tenant networks are created by specific tenants for use by their instances and cannot be shared (based on default policy settings).

Typically, the provider network is directly related to the physical network in the datacenter (that is, virtual LANs (VLANs)), but there are special cases. Of course, you can use the overlay protocol, such as a generic routing encapsulation (GRE) or a virtual extensible LAN, to provide an provider network, and then use a software or hardware gateway to map the overlay network to a physical network. Similarly, tenant networks can be instantiated using the underlying or overlay technology. In general, tenants do not know how their tenant network is implemented. In summary, the choice of a underlay or overlay technology usually does not affect whether the tenant network or provider network is available.

Finally, the provider network relies on the physical network infrastructure to provide the default gateway/first-hop routing service. Instead, the tenant network relies on the neutron router to implement it. Neutron routers must connect their upstream interfaces to a provider network that is designated as "external" to connect to the physical network.

Network security is now orthogonal to network topology.

Historically, network security has been applied only at the boundaries of the network (the third-tier boundary), usually using firewalls or routers. Recently, advanced technologies such as VLANs have enabled the so-called transparent firewalls. Now, with the neutron logical port used with the neutron security group, network security can be applied directly to each workload where the network is connected. Therefore, you can now use security groups instead of dedicated layer 2 networks to protect the security zones and protect the application layer.

In addition, neutron port security prevents 2nd-tier attack technologies such as Mac and IP spoofing.

In summary, these neutron features enable shared provider networks to be a viable alternative to tenant networks in application/security zones.

The Tenant network IP address space selection problem

When using a tenant network, tenants must specify the IP address space they want to use. How do tenants make the right choices? This is a more difficult challenge than at first glance. Let's assume that any source NAT or destination NAT will be used, so the tenant network IP address space will never be exposed outside the cloud.

Even in this case, tenants cannot select any IP address space they want (even in the RFC 1918 private address space). If the tenant chooses an IP address space (such as 10.10.10.0/24) that is used elsewhere in the enterprise, the corporate network will not be able to communicate with the tenant network. In addition, any other tenant network connected to the same neutron router cannot communicate with the corporate network. This is because the source IP address of the network traffic from outside the cloud is not affected by the NAT of OpenStack. OpenStack will only apply NAT to the source IP address of the network traffic originating from the tenant network. Because the 10.10.10.0/24 network is connected directly to an instance on the neutron router and the tenant network, the cloud traffic from the corporate network will never be able to find its path there.

This scenario does not appear in the public cloud if the tenant uses private address space for their network (because the cloud users are from the registered address space). However, in a private cloud environment, private address space is most likely to be used, and there are consumers of clouds from private address space.

Fortunately, in the Kilo version, a subnet pool is introduced as a mechanism for handling IP address space selection problems in the tenant network. Unfortunately, support for the subnet pool was implemented until the release was free.

"Neutron" Tenant Networks vs. Provider Networks