Dynamic network containers refers to the ability to modify containers after provisioning. BMC Network Automation added the ability to modify a container after it has been provisioned in version 8.2.01. Previously, once containers were provisioned, they were static, incapable of being modified. BMC Network Automation 8.6.00 expands the scope of dynamic network containers.
This topic contains the following sections:
The modify operation allows you to toggle components already defined within a container. The components that can be toggled are:
Other components connected to these are. The other components include:
The definition of the components that can be toggled comes from the network container blueprint used to provision the container. The network container blueprint defines the default toggle states for each component. The components that cannot be toggled are locked into the enable state. The components that are not locked can have their default state overridden during container provisioning.
BMC Network Automation supports the ability to add components to the container that were not originally defined in the network container blueprint. See Reprovisioning network containers.
When an external network is enabled, the FW interface that serves the external segment is enabled automatically, if there is an existing network path that has the dependent firewall as the serviced node and the external network as an endpoint segment and the other endpoint segment is an enabled NIC or VIP segment.
When an external network segment is disabled, the FW interface that serves the external segment is disabled automatically, along with any other interface that lies in the network path which has the external network as an endpoint.
VFWs are flagged as either independent or dependent. VFWs flagged as independent can be directly toggled using the API as part of a container provision or modify operation, in the same way that you can directly toggle a VLB. VFWs flagged as dependent can be toggled indirectly as a side effect of toggling a NIC segment or a VLB.
When a NIC segment is enabled, the following other components are enabled automatically:
When a NIC segment is disabled, the following other components are disabled automatically:
When a VLB is enabled, the following other components are enabled automatically:
When a VLB is disabled, the following other components are disabled automatically:
When an independent VFW is disabled, the following other components are disabled automatically:
If you attempt to enable a VFW while there are VMs present behind it, the traffic to those VMs would be blocked by default. Ideally, you would want traffic to continue to flow to those VMs just like it did prior to the VFW being enabled. To address this, you can specify an optional set of initial entries for ACL blueprints within the container blueprint. These entries are applied to the VFW when it is enabled during container provisioning or modification.
In addition, if there are persisted path rules in the network container, they are re-applied when a VFW is enabled.
The main advantage of having dynamic components within a network container is that it allows resources to be conserved within the container. If a resource is not needed by any of the components currently enabled, then you can defer acquiring it until a component that needs it is enabled.
The resources that can be conserved include both resource elements (VLANs, integers, addresses, and address pools) and resource collections (address spaces) owned by the container. You must define in the blueprint the conditions under which each resource should be acquired, as a boolean expression of component states. When the conditional expression evaluates to true, the resource is acquired, and when it evaluates to false, it is released. Resources for which no condition is defined are always acquired at provisioning time.
In addition to defining conditionals on resources to control when they are acquired and released, you need to define conditionals on configure actions to control how to use them in devices. When the conditional expression evaluates to true, the configure action is executed, and when it evaluates to false, the associated unconfigure action is executed. Associated configure and unconfigure actions are identified by sharing a common name attribute. Configure actions without a defined condition are always executed at provisioning time, and unconfigure actions without a defined condition are always executed at deprovisioning time.
When a modify operation is performed, you can override the default network addresses and masks for the address spaces that are acquired during the operation. You can also override the default sizes of the address pools within those spaces that are acquired during the operation.
There is currently a shortcoming in the dynamic network container functionality regarding guest nodes in fault host pairs. BMC Network Automation does not currently allow multiple actions to be defined for the create-guest, initialize-guest, or destroy-guest actions that are defined in the pair. This can be a problem if there is conditional logic involved in those actions.
There is typically not any conditional logic in the destroy-guest action, but the create-guest and init-guest actions typically do have conditional logic. For the init-guest action, you can break out the conditional logic into actions defined in the guest node. For the create-guest action however, you cannot do this. For the create-guest action, you must break out the conditional logic into actions defined in a dummy host node. The dummy host node is a vanilla node with a dummyHostFlag attribute set true, encapsulating a FW or LB device with a virtual IP address that points to the active admin context of the fault host pair.
Another shortcoming is that BMC Network Automation currently does not lock down the container during modification in order to prevent concurrent server provisioning. It is possible therefore for a container modification operation to be underway that is disabling a NIC segment, at the same time that someone is attempting to provision a server to that segment. BMC Network Automation currently relies on BMC Cloud Lifecycle Management to restrain itself from doing this.
In future, fault host pairs will support multiple create-guest, initialize-guest, and destroy-guest actions. This enhancement will eliminate the dummy host workaround described above.
The following table maps the dynamic components (those that can be toggled) to the associated treatment of legacy containers.
Legacy container information
Containers created prior to 8.2.01 which are upgraded to 8.3.00 are treated as static containers, and all VFWs are flagged as dependent (cannot be toggled directly) with their locked flag set to true.
NIC segments and VLBs
Containers created prior to 8.2.01 which are upgraded to 8.3.00 are treated as static containers, and all NIC segments and VLBs that can be toggled are locked into the enabled position.
External network segments
Containers created prior to 8.3.00 which are upgraded to 8.3.00 are treated as static containers, and all external network segments and external network segment blueprints that can be toggled are locked into the enabled position.
This is necessary because such legacy containers do not have the necessary conditional logic defined within them to support toggling. For example, container administrators cannot toggle external network segments in new containers created from blueprints created before 8.3.00, and cannot toggle external network segments in containers created before 8.3.00.
The structure of these conditionals is similar to the structure used for conditionals in device adapters. The
-EXISTS- operator is used to test whether a given named component is enabled, while the
-AND- operators are used to chain together existence terms into complex expressions. Each term in a complex expression must be enclosed in parentheses.
The syntax used to name components in the conditionals is similar to the syntax used to refer to components in container substitution parameters. The following table lists the syntax used to refer to the components whose state can be tested (the ones in italics are probably not necessary, since their state should always shadow the state of other components, but are supported just in case):
|Component Category||Component Type||Naming Syntax|
Virtual Port Type
LB Pool Type
FW Inbound ACL
FW Outbound ACL
Names that appear as indexes in these components must be surrounded by quotes if they contain spaces, for example:
container.nicSegments['My NIC Segment'].
In this example, you have a container blueprint that contains two NIC segments (called
NIC 1 and
NIC 2, both enabled by default), and one VLB (called
VLB, disabled by default). The container blueprint might define the following conditionals on various resources:
Acquire resource only when
Acquire resource only when
Acquire resource only when either segment is enabled
Acquire resource only when
If a container is provisioned using this blueprint, and the default toggle states, the container would have two NIC segments enabled and its VLB disabled initially. All resources needed by the NIC segments would be acquired, but those needed by the VLB would not be.
You could modify the container to enable the VLB, or disable one of the NIC segments for instance, which would acquire new resources and release old ones as needed based on evaluation of the conditionals. You could not, however, modify it to add a third NIC segment, because the blueprint did not define it.
There are a few places in the network container blueprint where conditionals are implicit, and do not have to be explicitly declared. These include:
When you are creating a network container, the state of dynamic components such as an external network segment, can be overridden as long as the associated blueprint does not define the external network segment as locked. Similar to external network segments, the state of independent VFWs can be overridden, as long as the associated blueprint defines the virtual firewall as independent and not locked. In addition, some subcomponents of the dynamic components can be overridden during network container creation. For example, the network address and network mask of an external network segment can be overridden during the network container creation process.
BMC Network Automation does the following when creating a container:
If an error occurs during container creation, BMC Network Automation automatically rolls back the container using the following steps:
If an error occurs during the rollback, the container is left in a partially deprovisioned state, which is not usable for provisioning servers. To fully deprovision this container, you must fix the error and.
When you edit a network container, the state of dynamic components, such as the external network segment or an independent VFW, can be toggled to enabled or disabled, if the component is not locked. In addition, some subcomponents of the dynamic components can be overridden when enabling. For example, the network address and network mask of an external network segment can be overridden when enabling the external network segment.
When an external network segment is disabled, the network address / network mask is NULLED out.
When you edit a container if an dynamic component is toggled, a container modification event is generated.
For example, consider an FT container which has the following topology. VLBs are not shown here for simplicity. All components shown here are initially in the enabled state.
When you disable the external network, you have a network path OUTSIDE_FE_NIC which has FE_VFW and firewall interfaces outside and inside. Therefore, disabling the external network will disable FE_VFW as well as the two firewall interfaces inside and outside.
When you enable the external network, FE_VFW and the two firewall interfaces Outside and Inside are enabled.
BMC Network Automation does the following when editing a network container:
If an error occurs while editing a container, you can roll it back by performing the following steps:
If an error occurs during the rollback, the container is left in a partially unmodified state, which is still usable for provisioning servers. To fully roll back the changes, you must fix the error and edit the network container operation again to toggle or untoggled the same components. You must get the container back to a fully modified or unmodified state before attempting to toggle additional components.
BMC Network Automation performs the following steps when deleting a container:
If an error occurs during the deletion, the container is left in a partially deprovisioned state, and it is not usable for provisioning servers. To fully delete the container, you must fix the error and delete the container again.
BMC Network Automation executes the actions below in the order listed during container creation (for actions whose conditionals are true, or for which no conditional is defined) and container editing (for actions whose conditionals are newly true)):
At each step in the above sequence, the order in which configure actions are executed within a given node is the order in which the actions were defined in the network container blueprint.
The order in which unconfigure actions are executed during container editing (for actions whose corresponding configure actions should no longer be applied) and container deleting (for actions whose corresponding configure action is applied, or for which there is no corresponding configure action) is the following:
At each step in the above sequence, the order in which unconfigure actions are executed within a given node is the order in which the actions were defined in the blueprint.
Dynamic network containers add another layer to an already complex entity. You should expect to do extensive testing of any new container blueprint you create which defines conditionals for dynamic behavior. There are several tools available to help with stand alone testing of containers. These include the following:
To recover from such failures, the administrator must fix the underlying cause of the failures in BMC Network Automation, then try the modification again. Generally, such fixes involve editing the underlying BMC Network Automation templates involved to correct either syntactical or logical errors, which the network devices rejected and which caused the earlier jobs to fail. The administrator must inspect the details of the failed jobs in BMC Network Automation to determine the errors in question and how they must be corrected. The administrator must possess network engineering expertise and detailed knowledge of the network container architecture in question to be able to resolve this issue.
Locate the container in the listing that has the template copy you want to edit and click the View icon.
On the Container Details page, click the Action Info Template link for the template copy.
On the pop-up that displays the template information, click Edit.
Edit the information in the Contents field.