Creating custom content

This section presents an example for creating your own custom Pod and Container Management (PCM) content, for cases when the reference content delivered with the system is not a suitable starting point. The process followed can be summarized as follows:

Gathering inputs

The first thing to do is gather necessary inputs from the cloud provider. The cloud provider should be able to provide you with topology diagrams for the pod and container you are modeling, information about the devices to be used in an initial pod which you can test on, and initial templates you can use to configure devices on the pod to represent containers.

Topology diagrams

The following diagram shows the layer 1/2 topology of a particular sample pod used in this example:

The pod consists of a Cisco 6500 IOS edge switch node (C6K) and a Cisco 1000V NexusOS access switch node (N1K). The devices used may change from one pod instance to the next. The black lines show connectivity for the data path to virtual machines (VMs). The blue lines show connectivity for the management paths to both VMs and switches.

The management path to switches is configured to use vlan 10 and subnet 10.0.0.0/28, and the management path to VMs is configured to use vlan 11 and subnet 11.0.0.0/24. The data path connecting the outside to the edge switch is configured to use vlan 20 and subnet 20.0.0.0/24. The data path connecting the edge switch to the access switch has no VLANs configured on it yet. VLANs are added later as containers are configured on the pod. The values shown here may change from one pod instance to the next.

The following diagram shows the layer 2 topology of a particular sample container used in this example. It is a max topology diagram, meaning that all togglable components within it are shown as enabled.

The container consists of an edge switch node and an access switch node. The black lines show connectivity for the data paths to VMs. The blue lines show connectivity for the management paths to both VMs and switches. Dotted lines show already configured connections which each container reuses, while solid lines show new connections configured for each container.

The management paths are already configured to use vlan 10 with subnet 10.0.0.0/28, and vlan 11 with subnet 11.0.0.0/24. The data path connecting the outside to the edge switch is already configured to use vlan 20 and subnet 20.0.0.0/24. The data path connecting the edge switch to the access switch is configured to use either vlan 21 and subnet 21.0.0.0/24 or vlan 22 and subnet 22.0.0.0/24.

VMs added to the access switch can connect Network Interface Controller (NICs) to receive management traffic on vlan 11 and data traffic on vlans 21 and 22. The resources for the data path connecting edge to access are shown in italics to indicate they are dynamic and are only acquired if the NIC segment they are associated with is enabled. Their values may change from one container instance to the next.

Device information

The following is information about the devices that can be used in a cloud provider test pod while developing our blueprints:

Name

Hostname address

Device type

Device category

Username

Password

Privileged password

Edge

Edge

Cisco IOS

Switch

MyUsername

MyPassword

MyPrivPassword

Access

Access

Cisco NOS

Switch

MyUsername

MyPassword

MyPrivPassword

The devices included should be ones whose configurations will change whenever a new container is provisioned on the pod.

Initial templates

The following are the initial templates for configuring and unconfiguring a max topology container on the pod. Values which change from one container instance to the next are identified as runtime parameters and given names, along with defaults to indicate what values an initial container instance would receive.

The InitialSampleConfigureEdge template has the following content:

vlan ${runtime.AccessAVlan:21}
interface vlan${runtime.AccessAVlan:21}
ip address ${runtime.GatewayAAddress:21.0.0.1} ${runtime.GatewayAMask:255.255.255.0}
no shutdown
exit
vlan ${runtime.AccessBVlan:22}
interface vlan${runtime.AccessBVlan:22}
ip address ${runtime.GatewayBAddress:22.0.0.1} ${runtime.GatewayBMask:255.255.255.0}
no shutdown
exit

The InitialSampleUnconfigureEdge template has the following content:

no vlan ${runtime.AccessAVlan:21}
no interface vlan${runtime.AccessAVlan:21}
no vlan ${runtime.AccessBVlan:22}
no interface vlan${runtime.AccessBVlan:22}

The InitialSampleConfigureAccess template has the following content:

port-profile ${runtime.AccessAVlan:21}
switchport mode access
switchport access vlan ${runtime.AccessAVlan:21}
vmware port-group ${runtime.AccessAVlan:21}
no shutdown
state enabled
exit
port-profile ${runtime.AccessBVlan:22}
switchport mode access
switchport access vlan ${runtime.AccessBVlan:22}
vmware port-group ${runtime.AccessBVlan:22}
no shutdown
state enabled
exit

The InitialSampleUnconfigureAccess template has the following content:

no port-profile ${runtime.AccessAVlan:21}
no port-profile ${runtime.AccessBVlan:22}

Verifying inputs

The next thing to do is verify that the inputs given to us are correct, before we start trying to use them as the basis for constructing our blueprints.

Creating device security profiles

In order to test connectivity to the devices provided, we need to define device security profiles (DSP) that specify their authentication credentials. Since both devices use the same credentials here, we would create the following single DSP in the BMC Network Automation user interface:

Name

Username

Password

Privileged password

MyDsp

MyUsername

MyPassword

MyPrivPassword

Creating and testing devices

Now we can create the devices in the BMC Network Automation user interface with the following values:

Name

Hostname address

Device type

Device category

DSP

Edge

Edge

Cisco IOS

Switch

MyDsp

Access

Access

Cisco NOS

Switch

MyDsp

After the devices are created, BMC Network Automation automatically attempts to create a snapshot of their configuration. Verify that the snapshots succeed before proceeding.

Our assumption is that the devices have already been configured correctly by the cloud provider in order to be used in this pod. This means both have been configured to receive switch management traffic over vlan 10, and the edge switch has been configured to receive data traffic over vlan 20. It also means the access switch has been configured to allow VM NICs to connect to vlan 11 for their management traffic using a port group named 11.

By witnessing the successful backup of the switches, we have already verified that BMC Network Automation can manage them via vlan 10. To verify that the edge switch can receive data traffic over vlan 20, you should try to ping it from the outside. This should be done using an outside client which you ultimately want to be able to use to connect to VMs in the pod via the data path.

To verify that the access switch has been configured to support VM management, you should test whether BMC Server Automation can be used to manage an existing VM connected using port group 11.

Creating and testing initial templates

Next we need to verify whether the initial templates provided can be used to successfully create containers on these devices. To do this we should use the BMC Network Automation user interface to create the four initial templates that were specified, then we should create two predefined jobs with deploy-to-active actions to test out those templates, one for configuring a container and another for unconfiguring a container.

Run the predefined job to configure a container, using the default values for the runtime parameters:

AccessAVlan = 21
AccessBVlan = 22
GatewayAAddress = 21.0.0.1
GatewayBAddress = 22.0.0.1
GatewayAMask = /24
GatewayBMask = /24

Verify that it succeeds, then run it again using the non-default values for the runtime parameters:

AccessAVlan = 23
AccessBVlan = 24
GatewayAAddress = 23.0.0.1
GatewayBAddress = 24.0.0.1
GatewayAMask = /24
GatewayBMask = /24

To verify the data paths in each container, connect an existing VM to the network using the port groups named 21 and 22, via separate NICs. Then connect another using the port groups named 23 and 24, via separate NICs. Verify that an outside client can connect to each VM, using either of its NIC addresses, but that the VMs cannot ping each other, indicating that the data paths of the containers are appropriately isolated from each other.

Identifying resources

Now that the necessary inputs have been gathered and verified, the next step is to organize the runtime parameters in the templates into resources which can be specified in our blueprints. To do this, BMC recommends creating a resource spreadsheet. The spreadsheet should cover both resource elements (VLANs and addresses) and collections (VLAN pools and address ranges). The spreadsheet is relatively small for this simplified example, but for more complicated cases it should be much larger.

The following spreadsheet tab describes VLAN resources:

Name

ID

Owner

Switch Management Vlan

10

Pod

VM Management Vlan

11

Pod

Edge Vlan

20

Pod

AccessA Vlan

21

Container 1

AccessB Vlan

22

Container 1

Here the values for each of the VLANs that appeared in our topology diagrams are recorded. For pod level vlans, we need to consider whether they are VLANs we need to know about when provisioning containers and VMs. Vlan 11 needs to be known because it is used when provisioning VMs and connecting their management NICs. Vlans 10 and 20 however do not need to be known, so they are italicized.

The following spreadsheet tab describes address resources:

Name

Address

Mask

Owner

GatewayA Address

21.0.0.1

/24

Container 1 Edge Switch

GatewayB Address

22.0.0.1

/24

Container 1 Edge Switch

Here the values for each address referenced in our templates are recorded. For container 1, GatewayAAddress is the gateway address for the 21.0.0.0/24 subnet while GatewayBAddress is the gateway address for the 22.0.0.0/24 subnet. VM NICs connected to vlan 21 in container 1 acquire addresses from the range 21.0.0.2-21.0.0.254. VM NICs connected to vlan 22 in container 1 acquire addresses from the range 22.0.0.2-22.0.0.254.

The following spreadsheet tab describes VLAN pool resources:

Name

Start ID

End ID

Management Vlans

11

11

Data Vlans

21

80

Here separate pools have been created to encapsulate the management and data VLANs. In the case of management VLANs there is only one involved. In the case of data VLANs there are two for each container expected. In the example, we propose to support up to 30 containers on this pod, which translates to 60 data VLANs.
The following spreadsheet tab describes address pool resources:

Name

Address

Mask

Owner

Switch Management Addresses

10.0.0.0

/28

Pod

VM Management Addresses

11.0.0.0

/24

Pod

Edge Addresses

20.0.0.0

/24

Pod

AccessA Addresses

21.0.0.0

/24

Container 1

AccessB Addresses

22.0.0.0

/24

Container 1

Here each of the subnets that appeared in our topology diagrams are represented. The switch management and edge addresses subnet are italicized since we do not need to know about them when provisioning containers and VMs.

The following spreadsheet tab describes address range resources:

Name

Address

Mask

Data Address Pools

21.0.0.0

/18

Here an address range which can be carved up into 64 pools of size /24 each is defined. This assumes that each container uses the next two available subnets from the range to use for its AccessA and AccessB address pools.

Since address spaces are not expected to be used in this container, we do not need a separate resource tab for it here.

Generating pod outputs

The steps for generating pod outputs are discussed in the sections that follow.

Creating a pod blueprint

The next step is to create a pod blueprint with the information we have assembled. For this step you should copy the pod blueprint XML skeleton from Pod blueprint XML reference to a file called SamplePodBlueprint.xml in C:\temp. You should then remove the following sections which are not needed in this example:

  • Resources: Integer Pools
  • Model: Simple Parameters
  • Model: Balanced Parameters
  • Model: Firewall Host Node
  • Model: Load Balancer Host Node
  • Model: Physical Switch Node
  • Model: Pairs

The following table lists the remaining sections you must populate:

Section

Comments

Identity

Specify the name tag as Sample Pod Blueprint.

Resources: Address Ranges

Populate using resource spreadsheet information.

Resources: Address Pools

Populate using resource spreadsheet information.

Resources: Vlan Pools

Populate using resource spreadsheet information.

Resources: Vlans

Populate using resource spreadsheet information.

Model: NIC Segments

Populate to reference the VLAN and address pool used for VM management.

Model: Vanilla Node

Populate to represent the edge switch.

Model: Hypervisor Switch Node

Populate to represent the access switch. Define a port type blueprint to represent the ability to connect VM management NICs.

The version tag for the file can be left unpopulated. Other unnecessary tags within the above sections can be left out altogether.

The completed pod blueprint XML file can be viewed in the public\bmc\bca-networks\csm\sample subdirectory where you have BMC Network Automation installed. Import the file into BMC Network Automation from the command line as follows:

cd C:\Program Files\BMC Software\BCA-Networks\public\bmc\bca-networks\extras\bcan-import-export\bin
.\import.bat -url <url> -user <user> -password <password> C:\temp\SamplePodBlueprint.xml

where:

  • <url> is the BMC Network Automation application server URL
  • <user> and <password> are the username and password of the BMC Network Automation account to use to perform the import.

The import should succeed, after which you can inspect the pod blueprint from the BMC Network Automation user interface.

Creating a pod

Use the wizard in the BMC Network Automation user interface to create a pod using this blueprint with the following non-default inputs:

Page

Field

Value

Pod Details

Name

Sample Pod

Pod Node: Edge

Device

Edge

Pod Node: Access

Device

Access

Address Pool: Management

Pool Address

11.0.0.0 / 24

Address Pool: Management

Gateway Address

11.0.0.1

Address Range: Data

Range Address

21.0.0.0 / 18

VLAN: Management

VLAN Number

11

Verify the pod creation succeeded, after which you can inspect the pod from the BMC Network Automation user interface.

Creating static container outputs

Next we need to create the templates and blueprints necessary to allow us to create and test a static container for our sample topology.

Creating static templates

We need to create new versions of our templates to replace runtime substitution parameters with container substitution parameters. Use the substitution parameters information popup in the BMC Network Automation template editor to remind you of the proper syntax to use.

The SampleStaticConfigureEdge template has the following content:

vlan ${container.vlans[AccessA]}
interface vlan${container.vlans[AccessA]}
ip address ${container.node.addresses[GatewayA]} ${container.node.addresses[GatewayA].subnetMask}
no shutdown
exit
vlan ${container.vlans[AccessB]}
interface vlan${container.vlans[AccessB]}
ip address ${container.node.addresses[GatewayB]} ${container.node.addresses[GatewayB].subnetMask}
no shutdown
exit

The SampleStaticUnconfigureEdge template has the following content:

no vlan ${container.vlans[AccessA]}
no interface vlan${container.vlans[AccessA]}
no vlan ${container.vlans[AccessB]}
no interface vlan${container.vlans[AccessB]}

The SampleStaticConfigureAccess template has the following content:

port-profile ${container.node.portTypes[AccessA].name}
switchport mode access
switchport access vlan ${container.node.portTypes[AccessA].vlan}
vmware port-group ${container.node.portTypes[AccessA].vlan}
no shutdown
state enabled
exit
port-profile ${container.node.portTypes[AccessB].name}
switchport mode access
switchport access vlan ${container.node.portTypes[AccessB].vlan}
vmware port-group ${container.node.portTypes[AccessB].vlan}
no shutdown
state enabled
exit

The SampleStaticUnconfigureAccess template has the following content:

no port-profile ${container.node.portTypes[AccessA].name}
no port-profile ${container.node.portTypes[AccessB].name}

Creating a static container blueprint

The next step is to create a container blueprint using the assembled information. For now it should represent a static max topology. Once we get that working we can add dynamic behavior.

For this step you should copy the container blueprint XML skeleton from see Container blueprint XML reference to a file called SampleStaticContainerBlueprint.xml in C:\temp. You should then remove the following sections which are not needed in this example:

  • Resources: Address Spaces
  • Resources: Addresses
  • Resources: Integers
  • Model: VRF IDs
  • Model: VIP Segments
  • Model: Zones
  • Model: Firewall Host Node
  • Model: Load Balancer Host Node
  • Model: Physical Switch Node
  • Model: Pairs

The following table lists the remaining sections you must populate:

Section

Comments

Identity

Specify the name tag as Sample Static Container Blueprint. Drop the diagramLink, legacyVersion, tag and type tags as unnecessary.

Resources: Address Pools

Populate using resource spreadsheet information. For now these resources should be unconditionally acquired.

Resources: Vlans

Populate using resource spreadsheet information. For now these resources should be unconditionally acquired.

Model: External Segments

Populate to represent the entire internet by default.

Model: NIC Segments

Populate with an instance to reference the VLAN and address pool used for access A, tagged by default for use with web traffic, and another instance to reference the VLAN and address pool used for access B, tagged by default for use with database traffic. For now these segments should be locked into the enabled state.

Model: Network Paths

Populate with an instance to reference data path A, and another instance to reference data path B.

Model: Vanilla Node

Populate to represent the edge switch, including address blueprints for gateways A and B, and merge actions to configure and unconfigure the switch using the relevant templates, which for now should be unconditionally executed.

Model: Hypervisor Switch Node

Populate to represent the access switch, including merge actions to configure and unconfigure the switch using the relevant templates, which for now should be unconditionally executed. Define one port type blueprint to represent the ability to connect VM web NICs, and to represent the ability to connect VM database NICs.

The version tag for the file can be left unpopulated. Other unnecessary tags within the above sections can be left out altogether.

The completed container blueprint XML file can be viewed in the public\bmc\bca-networks\csm\sample subdirectory where you have BMC Network Automation installed. Import the file into BMC Network Automationfrom the command line as follows:

.\import.bat -url <url> -user <user> -password <password> C:\temp\SampleStaticContainerBlueprint.xml

The import should succeed, after which you can inspect the container blueprint from the BMC Network Automation user interface.

Creating and testing a static container

Now you can use the pod and static container blueprint to create a static container from the BMC Network Automation command line as follows:

cd C:\Program Files\BMC Software\BCA-Networks\public\bmc\bca-networks\extras\bcan-pcm-utility\bin
.\container-util.bat -url <url> -user <user> -password <password> -operation provision_container -podName "Sample Pod" -containerBlueprintName "Sample Static Container Blueprint" -containerName "Sample Static Container"

The container creation should succeed, after which you can inspect the container from the BMC Network Automation user interface.

You can verify the ability to acquire addresses for a VM in this container by entering the following commands from the BMC Network Automation command line interface:

.\container-util.bat -url <url> -user <user> -password <password> -operation acquire_virtual_server_nic_address -containerName "Sample Static Container" -accessSwitchName Access -attachPointName Management -nicServerName MyServer -nicName 0

.\container-util.bat -url <url> -user <user> -password <password> -operation acquire_virtual_server_nic_address -containerName "Sample Static Container" -accessSwitchName Access -attachPointName AccessA -nicServerName MyServer -nicName 1

.\container-util.bat -url <url> -user <user> -password <password> -operation acquire_virtual_server_nic_address -containerName "Sample Static Container" -accessSwitchName Access -attachPointName AccessB -nicServerName MyServer -nicName 2

This should acquire an address from the Management pool for the NIC named 0, an address from the AccessA pool for the NIC named 1, and an address from the AccessB pool for the NIC named 2, where each is a NIC on a server named MyServer

Assign these to the respective NICs of an existing VM, where NIC 0 is connected to the network using the port group named 11, NIC 1 using the port group named 21, and NIC 2 using the port group named 22. Verify that you can manage the VM from BMC Server Automation, and that an outside client can connect to the VM using either of its NIC addresses.

You can release these VM addresses by entering following command from the BMC Network Automation command line interface:

.\container-util.bat -url <url> -user <user> -password <password> -operation release_all_server_nic_addresess -containerName "Sample Static Container" -nicServerName MyServer

You can then deprovision the container by entering following command from the BMC Network Automation command line interface:

.\container-util.bat -url <url> -user <user> -password <password> -operation deprovision_container -containerName "Sample Static Container"

Creating dynamic container outputs

Next we need to create the templates and blueprints necessary to allow us to create and test a dynamic container for our sample topology, in which each of the NIC segments in the container can be toggled.

Creating dynamic templates

We need to create new versions of our templates in which the commands to configure each of the NIC segments are broken out into separate templates. We will suffix the name of each template to identify which NIC segment it deals with.

The SampleDynamicConfigureEdge-A template has the following content:

vlan ${container.vlans[AccessA]}
interface vlan${container.vlans[AccessA]}
ip address ${container.node.addresses[GatewayA]} ${container.node.addresses[GatewayA].subnetMask}
no shutdown
exit

The SampleDynamicConfigureEdge-B template has the following content:

vlan ${container.vlans[AccessB]}
interface vlan${container.vlans[AccessB]}
ip address ${container.node.addresses[GatewayB]} ${container.node.addresses[GatewayB].subnetMask}
no shutdown
exit

The SampleDynamicUnconfigureEdge-A template has the following content:

no vlan ${container.vlans[AccessA]}
no interface vlan${container.vlans[AccessA]}

The SampleDynamicUnconfigureEdge-B template has the following content:

no vlan ${container.vlans[AccessB]}
no interface vlan${container.vlans[AccessB]}

The SampleDynamicConfigureAccess-A template has the following content:

port-profile ${container.node.portTypes[AccessA].name}
switchport mode access
switchport access vlan ${container.node.portTypes[AccessA].vlan}
vmware port-group ${container.node.portTypes[AccessA].vlan}
no shutdown
state enabled
exit

The SampleDynamicConfigureAccess-B template has the following content:

port-profile ${container.node.portTypes[AccessB].name}
switchport mode access
switchport access vlan ${container.node.portTypes[AccessB].vlan}
vmware port-group ${container.node.portTypes[AccessB].vlan}
no shutdown
state enabled
exit

The SampleDynamicUnconfigureAccess-A template has the following content:

no port-profile ${container.node.portTypes[AccessA].name}

The SampleDynamicUnconfigureAccess-B template has the following content:

no port-profile ${container.node.portTypes[AccessB].name}

Creating a dynamic container blueprint

We need to create a new version of our container blueprint in which we add conditions to resources and actions, identify which should be tied to the state of a particular NIC segment. Copy the static container blueprint to a new file named SampleDynamicContainerBlueprint.xml in C:\temp.

The following sections will be modified in it:

Section

Comment

Identity

Change name to Sample Dynamic Container Blueprint.

Resources: Address Pools

Add conditionals.

Resources: Vlans

Add conditionals.

Model: NIC Segments

Unlock each segment, and set the AccessB segment to disabled by default.

Model: Vanilla Node

Replace actions referring to static templates with multiple actions referring to dynamic templates, where each action has a name and each configure action has a conditional.  Add conditionals to address resources.

Model: Hypervisor Switch Node

Replace actions referring to static templates with multiple actions referring to dynamic templates, where each action has a name and each configure action has a conditional.

The completed container blueprint XML file can be viewed in the public\bmc\bca-networks\csm\sample subdirectory where you have BMC Network Automation installed. Import the file into BMC Network Automation from the command line as follows:

.\import.bat -url <url> -user <user> -password <password> C:\temp\SampleDynamicContainerBlueprint.xml

The import should succeed, after which you can inspect the container blueprint from the BMC Network Automation user interface.

Creating and testing a dynamic network container

You can use the network container blueprint to create a test dynamic network container from the BMC Network Automation command line interface as follows:

.\container-util.bat -url <url> -user <user> -password <password> -operation provision_container -podName "Sample Pod" -containerBlueprintName "Sample Dynamic Container Blueprint" -containerName "Sample Dynamic Container"

The network container creation should succeed, with AccessA initially enabled and AccessB initially disabled, after which you can inspect the network container from the BMC Network Automation user interface.

You can modify the container to enable the AccessB segment from the BMC Network Automation command line as follows:

.\container-util.bat -url <url> -user <user> -password <password> -operation modify_container -containerName "Sample Dynamic Container" -nicSegmentOverrides "AccessB:true"

The container modification should succeed, with AccessB initially being enabled, after which you can inspect the container from the BMC Network Automation user interface.

You can then deprovision the container entering the following command from the BMC Network Automation command line interface:

.\container-util.bat -url <url> -user <user> -password <password> -operation deprovision_container -containerName "Sample Dynamic Container"

Creating and testing a network container blueprint for a reprovisioning operation

You can use the network container blueprint to create a test reprovisioning operation that will make revised network container from the BMC Network Automation command line interface as follows:

container-util.sh -url <url> -user <user> -password <password> -operation reprovision_container -containerBlueprintName "Sample Dynamic Container Blueprint"#1 -containerName dynamicContainer

The reprovisioning operation should succeed, and you can inspect the revised network container from the BMC Network Automation user interface to validate the settings.

Was this page helpful? Yes No Submitting... Thank you

Comments