Network resources overview

BMC Network Automation defines and provides network resources for clouds defined by BMC Cloud Lifecycle Management. BMC Network Automation organizes cloud network resources by the following hierarchy:

• One or more pods at a location
• One or more network containers within a pod

Networks, virtual firewalls, and virtual load balancers reside at the network container level. Zones reference a set of networks. Networks can reside in multiple zones or in no zone. A network container does not have to have a zone. Neither firewalls nor load balancers are required to reside in zones.

Multiple networks can share the same BMC Cloud Lifecycle Management network label. For more information on BMC Cloud Lifecycle Management network labels, see Configuring network resources.

Locations

A location is a physical location, such as a building, and is defined using the Application Administration Console of the BMC Remedy IT Service Management (ITSM) Suite. For more information, see Creating a physical location for a pod.

Pods

A pod represents a physical layer-2 portion of the cloud. A pod is created on a group of co-located network hardware, such as routers, firewalls, and load balancers, and segregates cloud networks from other pods and non-cloud networks. Because these resources reside physically close to each other, pods are useful for organizing network resources by geographic location. For example, a cloud administrator might configure separate pods for the portions of the network in San Jose and Dallas.

Pods can physically overlap in order to make efficient use of the hardware involved. However, these overlapping pods are logically separated by routing.

Pods are created in BMC Network Automation using pod blueprints, which define the pod architecture and include a definition of the physical pod topology. After a pod is created, you can then onboard the pod into BMC Cloud Lifecycle Management.

For more information, see Creating network pod blueprints and Creating network pods.

Network containers

Network containers represent virtual layer-2 segments in a pod, isolating a segment of the network for specific tenants or workloads, based on specific policies and rules. For example, a service provider might create network containers for two different tenants that use network resources in the San Jose pod. Although all of the resources are physically located in San Jose, each tenant has access only to the resources in that tenant's network container. Multiple network containers can exist within each pod. A network container is also known as a virtual data center (VDC).

Network containers are built from network container blueprints, which define the network container architecture. They can include definitions for firewalls, routers, load balancers, networks, and zones. For more information, see Creating network container blueprints and Creating network containers.

Dynamic aspects of network containers

Network containers have dynamic components that you can manage after you have provisioned the network container. Specifically, you can enable or disable load balancers and networks.

If a network that resides in a zone is enabled, then the zone becomes enabled if it is not already so. If a network that resides in a zone is disabled, then the zone becomes disabled if no other enabled networks reside in it.

Firewalls follow a similar rule. The firewall is enabled if the first network to which it is connected is enabled. And the firewall is disabled if the last network to which it is connected is disabled.

You can enable or disable load balancers independently of networks.

You cannot disable a network if virtual machines are attached to it. You cannot disable a load balancer if any load balancer pools are attached.

The network container blueprint definitions determine whether the network container is dynamic and whether it can support user-specified network addresses (Network Address Translation). During network container onboarding, a special template is applied to enable the dynamic features.

The container blueprint does not impose any constraints on the network names defined in it. The network names represent the associated BMC Cloud Lifecycle Management network segment. The network names are free form and do not following any predefined format. For more information on network names in container blueprints, see Container blueprint XML reference.

Network zones

A network zone represents a finer partitioning of network resources to isolate workloads. The need for this level of structure is driven by security and performance requirements. A network resource can be within a single zone or it can exist outside of zones completely. Pod-level networks exist outside of zones. A VM NIC will be in either 1 zone or no zones, depending on the network type (pod or container) into which it is placed.

Networks

A network represents a logical abstraction of one or more virtual LANs (VLANs) in a network, where those VLANs share the same quality of service characteristics. You can define networks at the pod level and the container level. For example, you might use a pod-level network to allow BMC Cloud Lifecycle Management components to communicate, and a container-level network to allow communication between the infrastructure resources that are provisioned as a result of service requests. Networks can span network zones and network containers.

The following image shows a sample network configuration, in which a single pod contains four network containers. Each network container includes 1 or more zones.

Sample network configuration

These methods of partitioning resources in network containers and zones are managed by network container blueprints. The cloud administrator can create any number of network container blueprints per pod.

When creating a network container, the cloud administrator must specify its name, the associated pod, and a network container blueprint to use for provisioning resources in that container. Each network container can be mapped to one or more compute resource pools. Each network container can also be mapped to one or more tenants. If a network container is mapped to more than one tenant, when a cloud end user makes a request, compute resources are provisioned to network containers based on which tenant made the request. For more information about tenants, see Tenant management overview.

IP address management

The cloud administrator manages IP addresses associated to network containers through BMC Network Automation and an integration with third-party IP address management systems. When provisioning compute resource containers, BMC Cloud Lifecycle Management relies on BMC Network Automation to assign IP addresses from the pool of addresses available within the associated network container. IP address pools can also be configured at the pod level to manage networks spanning multiple network containers within that pod.

BMC Network Automation uses two addressing schemes, pod-oriented addressing and container-oriented addressing for IP address management (IPAM) to define resources. See Addressing schemes for more information.

When a server is added to a network container, the IPAM system acquires addresses for its NICs from address pools within the container. When the server is removed, the addresses that the server used are released back to the IPAM system.

For more information about configuring IPAM, see Enabling IP address management.