Page tree
Skip to end of metadata
Go to start of metadata

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:

Components that can be toggled within a container

The modify operation allows you to toggle components already defined within a container. The components that can be toggled are:

  • external network segments (as of version 8.3.00)
  • network interface controller (NIC) segments (as of version 8.2.01)
  • Virtual Loadbalancers (VLBs - as of version 8.2.01)
  • independent Virtual Firewalls (VFWs - as of version 8.3.00)

Other components connected to these are automatically toggled as a side effect. The other components include:

  • zones
  • virtual port types
  • Virtual Internet Protocol (VIP) segments
  • Loadbalancer (LB) pool types
  • Firewall (FW) access control lists (ACLs)
  • FW interfaces
  • dependent VFWs

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.

Back to top

Toggle side effects

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:

  • Virtual port types that are connected to the NIC segment.
  • FW interface that secures traffic for the NIC segment is enabled only when the interface is bounded by a supporting network path. For example, consider that you have an external network segment, Outside and a NIC segment, NIC Segment 2 serviced by firewall interface, Interface2 on firewall VFW. When you enable NIC Segment 2, Interface2 is enabled only if there is a network path, Outside – NIC Segment 2 with VFW as a service node.
  • Dependent VFWs for the associated FW interfaces.
  • LB pool types that balance traffic for the NIC segment, if their associated VLBs are already enabled.
  • Zones for the NIC segment.

When a NIC segment is disabled, the following other components are disabled automatically:

  • Virtual port types that are connected to the NIC segment.
  • FW interfaces that secure traffic for the NIC segment, if they are not still securing other traffic are disabled only when there is a supporting network path.
  • Dependent VFWs for the associated FW interfaces, if they have no other FW interfaces still enabled.
  • LB pool types that balanced traffic for the NIC segment, if they are not still balancing other traffic.
  • Zones for the NIC segment, if they have no other segments still enabled.

When a VLB is enabled, the following other components are enabled automatically:

  • Virtual port types within them that balance traffic for enabled NIC segments.
  • VIP segments connected to those virtual port types.
  • FW interfaces that secure traffic for those VIP segments.
  • Dependent VFWs for the associated FW interfaces.
  • Zones for the VIP segments.

When a VLB is disabled, the following other components are disabled automatically:

  • Virtual port types within them.
  • VIP segments connected to those virtual port types.
  • FW interfaces that secure traffic for those VIP segments, if they are not still securing other traffic.
  • Dependent VFWs for the associated FW interfaces, if they have no other FW interfaces still enabled.
  • Zones for the VIP segments, if they have no other segments still enabled.

When an independent VFW is disabled, the following other components are disabled automatically:

  • Underlying FW interfaces.
  • ACLs associated with FW interfaces.

Back to top

ACL initialization and re-application of path rules

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.

Back to top

Resource conservation

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.

Note

Configure and unconfigure actions can be specified for guest nodes, in order to allow their content to be conditionally constructed.

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.

Back to top

Shortcomings

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.

Back to top

Legacy containers

The following table maps the dynamic components (those that can be toggled) to the associated treatment of legacy containers.

Dynamic components

Legacy container information

VFWs

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.

Note

 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.

Back to top

Syntax of the Boolean expression

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 -OR- and -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 CategoryComponent TypeNaming Syntax

Container Component

NIC Segment

container.externalNetworkSegments[<segment-name>]

Container Component

NIC Segment

container.nicSegments[<segment-name>]

Container Component

VIP Segment

container.vipSegments[<segment-name>]

Zone Component

Zone

container.zones[<zone-name>]

Zone Component

NIC Segment

container.zones[<zone-name>].nicSegments[<segment-name>]

Zone Component

VIP Segment

container.zones[<zone-name>].vipSegments[<segment-name>]

Switch Component

Virtual Port Type

container.nodes[<switch-name>].attachPoints[<attach-point-name>]

VLB Component

VLB

container.nodes[<vlb-name>]

VLB Component

LB Pool Type

container.nodes[<vlb-name>].poolTypes[<pool-type-name>]

VFW Component

VFW

container.nodes[<vfw-name>]

VFW Component

FW Interface

container.nodes[<vfw-name>].managedInterfaces[<interface-name>]

VFW Component

FW Inbound ACL

container.nodes[<vfw-name>].managedInterfaces[<interface-name>].inboundAcl

VFW Component

FW Outbound ACL

container.nodes[<vfw-name>].managedInterfaces[<interface-name>].outboundAcl

Note

 Names that appear as indexes in these components must be surrounded by quotes if they contain spaces, for example: container.nicSegments['My NIC Segment'].

Back to top

Example

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:

ExpressionMeaning

-EXISTS- container.nicSegments['NIC 1']

Acquire resource only when NIC 1 segment is enabled

-EXISTS- container.nicSegments['NIC 2']

Acquire resource only when NIC 2 segment is enabled

(-EXISTS- container.nicSegments['NIC 1']) -OR- (-EXISTS- container.nicSegments['NIC 2'])

Acquire resource only when either segment is enabled

-EXISTS- container.nodes[VLB]

Acquire resource only when VLB is enabled

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.

Back to top

Implicit conditionals

There are a few places in the network container blueprint where conditionals are implicit, and do not have to be explicitly declared. These include:

  • Address blueprints are only acquired when the address pool they come from has already been acquired.
  • Guest addresses are only acquired when the virtual guest node they belong to has already been enabled.
  • Guest actions are only executed when the virtual guest node they belong to has already been enabled.
  • Create-guest and init-guest actions in a fault host pair are only executed when the virtual guest node involved is being enabled.
  • The destroy-guest action in a fault host pair is only executed when the virtual guest node involved is being disabled.

Back to top

Creating a network container

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:

  • Creates a hollow container using the container blueprint, and includes any default overrides requested.
  • Acquires resources with conditionals that are true.
  • Executes configure actions with conditionals that are true.

If an error occurs during container creation, BMC Network Automation automatically rolls back the container using the following steps:

  • Executes unconfigure actions for which a corresponding configure action was previously executed, or for which there is no corresponding configure action.
  • Releases resources that were previously acquired.
  • Deletes the container.

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 delete the container.

Back to top

Editing a network container

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. 

Note

 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.

  • External Network Segment: {External Network}
  • ContainerNicNetworkSegments: {FE_NIC, BE1_NIC, and BE2_NIC}
  • FE_VFW: (Firewall)
    • Interfaces: inside {servicedSegments = "FE_NIC"} and outside {servicedSegments="External Network"}
  • BE_VFW (Firewall)
    • Interfaces: outside {bridged to FE_VFW.inside} and inside {servicedSegments="BE1_NIC, BE2_NIC"}
  • Network Paths:
    • OUTSIDE_FE_NIC: {outside – FE_NIC, servicedNodes={FE_VFW}}
    • FE_NIC_BE1_NIC: {FE_NIC – BE1_NIC, servicedNodes={BE_VFW}}
    • FE_NIC_BE2_NIC: {FE_NIC-BE2_NIC, servicedNodes={BE_VFW}}

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:

  • Toggles requested component states within container.
  • Executes unconfigure actions with corresponding configure action conditionals that are no longer true.
  • Releases resources with conditionals that are no longer true.
  • Acquires resources with conditionals that are now true.
  • Executes configure actions with conditionals that are now true.

If an error occurs while editing a container, you can roll it back by performing the following steps:

  1. Restore components to their previous states within container.
  2. Execute unconfigure actions for which a corresponding configure action was previously executed, whose corresponding configure action with conditionals that are no longer true.
  3. Release resources which were previously acquired with conditionals that are no longer true.
  4. Acquire resources which were previously released with conditionals that are now true.
  5. Execute configure actions for which a corresponding unconfigure action was previously executed with conditionals that are now true.

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.

Back to top

Deleting a container

BMC Network Automation performs the following steps when deleting a container:

  • Executes unconfigure actions for which a corresponding configure action was previously executed, or for which there is no corresponding configure action.
  • Releases resources which were previously acquired.
  • Deletes the 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.

Back to top

Action execution order

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)):

  1. Executes configure actions for regular (non-guest and non-dummy host) nodes.
  2. Executes create-guest actions for fault host pairs.
  3. Executes configure actions for dummy host nodes.
  4. Executes init-guest actions for fault host pairs.
  5. Executes configure actions for guest nodes.

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:

  • Executes unconfigure actions for guest nodes.
  • Executes unconfigure actions for dummy host nodes.
  • Executes destroy-guest actions for fault host pairs.
  • Executes unconfigure actions for regular nodes.

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.

Back to top

Troubleshooting dynamic network containers

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:

  • You can create test containers. See Creating and testing a dynamic network container and Creating and testing a network container blueprint for a reprovisioning operation subsections of the Creating dynamic container outputs section.
  • You can control whether BMC Network Automation performs a trailing commit in configure or unconfigure Deploy to Active actions using the vdcCommitContainerActions property in the global.properties file. This property has a default value of true.
  • You can skip the rollback logic after a failed provisioning attempt using the vdcSkipProvisioningRollback property in the global.properties file. This property has a default value of false.

    For example, if the vdcSkipProvisioningRollback flag is set to true and you attempt to provision a container, and it fails with an error in action 19 out of 20, the deprovisioning rollback is skipped and the container is left in a partially provisioned state. You can then fix the error and execute a modify operation in which you do not change any toggle states. This causes BMC Network Automation to execute actions 19 and 20 from the original provision attempt, which completes the provisioning logic.
  • You can skip the rollback logic after a failed modify attempt using the skipUnmodifyFlag flag in the modify container API. This flag has a default value of false.

    For example, if the flag is set to true and you attempt to modify a container, and it fails with an error in action 19 out of 20, the unmodify rollback is skipped and the container is left in a partially modified state. You can then fix the error and re-execute the modify operation. This causes BMC Network Automation to execute actions 19 and 20 from the original attempt, which completes the modification logic.
  • You can ignore any failed actions during the modify sequence using the ignoreModifyErrorsFlag flag in the modify container API. This flag has a default value of false.
  • You can ignore any failed actions during the unmodify (rollback) sequence after a failed modify attempt using the ignoreUnmodifyErrorsFlag flag in the modify container API. This flag has a default value of false.
  • When a modify operation fails, and the automatic unmodify (rollback) operation also fails, the container is left in a partially modified state which might disrupt existing traffic, depending on the type of modifications which were being attempted. If the modifications are purely additive to the underlying configurations of the network devices involved, existing traffic is probably not disrupted. If however the modifications involved a mixture of both additions and subtractions to those configurations, existing traffic might indeed be disrupted.

    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.

  • You can replace the contents of a template copy within a container from the Container Details page in the BMC Network Automation user interface by performing the following steps:
    1. Open the Containers page by navigating to Network > Virtual Data Center > Containers.
    2. Locate the container in the listing that has the template copy you want to edit and click the View icon.

    3. On the Container Details page, click the Action Info Template link for the template copy.

    4. On the pop-up that displays the template information, click Edit.

    5. Edit the information in the Contents field.

    6. Click Save.

  • You can view the contents of a template copy within a container using the BMC Network Automation Containers viewer (navigate to Network > Virtual Data Center > Containers in the user interface). This is useful as a means of verifying the current contents of a template within a container after you have modified it, as described above.

Back to top