Configuring VMware NSX (SDN) platform

This topic provides information about the Pod and Container Management (PCM) changes and requirements to support the management of VMware NSX platform using BMC Network Automation as part of a BMC Cloud Lifecycle Management implementation. 

• Overview of the NSX environment
• Mapping of NSX components to device adapters
• Adding devices in BMC Network Automation
• Making configuration changes through injection templates and custom actions
• Pod requirements
• Container management
• Sample pod and container blueprints

VMware NSX is compatible with BMC Cloud Lifecycle Management 4.6.05 and later and BMC Network Automation 8.9 with Hot Fix 15.

Overview of the NSX environment

NSX is a software-defined networking (SDN) platform for VMware in which the NSX Manager acts as the SDN controller. NSX provides a complete set of logical networking elements and services including logical switching, routing, firewalling, load balancing, VPN, Quality of service (QoS), and monitoring.  

NSX environment has the following main components:

• NSX Manager: Provides a centralized management plane across your datacenter. It provides the vCenter Web Client UI (under Networking and Security) and REST API for NSX, which help you view and manage the NSX model. Upon installation, the NSX Manager injects a plugin into the vSphere Web Client for consumption within the web management platform. 
• NSX Controllers: Enables you to distribute network information to hosts. Controllers are in the form of VMs deployed during NSX installation.

Mapping of NSX components to device adapters

BMC Network Automation uses REST API calls to communicate with NSX Manager and performs GET, POST, PUT, and DELETE operations in order to get, add, modify, or delete NSX configurations. BMC Network Automation supports the following device adapters for NSX components. These adapters access NSX Manager to manage specific components.

• VMware NSX Manager: In BMC Network Automation, NSX Manager is represented as a device of type Vmware NSX Manager, whose address is the IP address of the NSX Manager. When BMC Network Automation captures a snapshot of its configuration, it captures a copy of the entire NSX object model. 
• VMware NSX Edge: An individual Edge VM (service gateway or distributed router) within NSX is represented in BMC Network Automation as a device of type VMware NSX Edge, whose IP address is the same as the NSX Manager, but whose user-defined security context name matches the name of the Edge VM instance within NSX. When BMC Network Automation captures a snapshot of its configuration, it captures just the portion of the NSX object model that corresponds to that Edge VM instance. This device adapter supports multi-context devices with User-Defined security context only.
• VMware NSX Distributed Firewall: An individual section within the NSX global firewall rules is represented in BMC Network Automation as a device of type VMware NSX Distributed Firewall, whose IP address is the same as the NSX Manager, but whose security context name matches the name of the section within NSX. When BMC Network Automation captures a snapshot of its configuration, it captures just the portion of the NSX object model that corresponds to that section within the global firewall rules. If the security context type is set to Admin instead of User-Defined, it corresponds to the Default section within the global firewall rules. This device adapter supports multi-context devices using section name of the distributed firewall.

Adding devices in BMC Network Automation

You must add devices in BMC Network Automation for VMware NSX, using the procedure to add a device in the BMC Network Automation documentation. When you perform the procedure, you must configure the following values in the Device Type field for each device:

• VMware NSX Manager
• VMWare NSX Distributed Firewall
• VMware dvSwitch

When you add an NSX distributed firewall, select Admin for Security Context.

Making configuration changes through injection templates and custom actions

You can push configuration changes to all the NSX device types through injection templates. Injection templates are templates whose contents are an XML snippet of the same form that is used in device commands within the device adapters. When you push the template through a Deploy to Active operation, the snippet is inserted in place of the injectTemplate tag within the device adapter, and interpreted at run time. This allows you to embed REST API style interactions within the XML snippet, to make changes to a device that does not support CLI-based commands. For more information, see Using injection templates to change device configuration.

In addition to using the injection templates for pushing the changes, BMC Network Automation includes the following custom actions to perform common NSX configuration tasks. For a few parameters that you need to provide while executing these custom actions, you need to access vCenter. For details, see gathering inputs for pods.

_{Back to top}

Pod requirements

Before you start creating an NSX POD, ensure that the following prerequisites are met:

• While adding pod nodes, they must be assigned particular node types and host devices with particular device types as follows:

  Pod node	Node type	Device type of the host device
  EdgeGatewayHost	Vanilla	VMware NSX Manager
  DistrbutedRouterHost	Vanilla	VMware NSX Manager
  DistributedFirewallHost	Firewall	VMWare NSX Distributed Firewall with Admin as the security context
  Access	Hypervisor Switch	VMware vSwitch

• Gather the values for the following attributes that you need to provide during pod creation: 

  Attribute	Steps to gather the value
  datacenterID	Browse to the following link: https://vCenterIP/mob. Look for the content property and click the content hyperlink in the VALUE column. Look for rootFolder and click the group-d<suffix> hyperlink. Look for childEntity. Record its value as the datacenterID. In this example, datacenter-2 is the datacenterID.
  datastoreID	Click the datacenter ID (datacenter-2) that you obtained in a previous step. Look for datastore. Record its value as the datastoreID. In this example, datastore-10 is the datastoreID.
  resourcePoolID	Click the datacenter ID (datacenter-2) that you obtained in a previous step. Look for hostFolder. In its value, click the group-h<suffix> hyperlink. Look for childEntity. Its value shows the clusters. Click the required cluster hyperlink. Look for resourcePool. Record its value as the resourcePoolID.  In this example, resgroup-49 is the resourcePoolID.
  Port Group Object IDs	Click the required cluster hyperlink (domain-c48) that you obtained in a previous step. Look for network. Its value shows object IDs of various port groups and logical switch virtual wires. In this example, network-11 and dvportgroup-86 are the object IDs for port groups.
  scopeID	Run the following GET REST API call using any of the REST clients: https://NSX-Manager-IP/api/2.0/vdn/scopes Look for the objectId tag. Record its value as the scopeID.   In this example, vdnscope-1 is the scopeID.

_{Back to top}

Container management

This section describes the container structure, requirements, and provisioning sequence. It also describes how ACL updates occur in containers.

Container structure

NSX does not have explicit concept of tenancy within its environment. However, it supports mechanisms for layer 2 segregation (VXLANs associated with logical switches), layer 3 segregation (north-south routing in NSX service gateway (a type of NSX Edge), and east-west routing in NSX distributed routers (another type of NSX Edge)). Logical switches are connected through interfaces on those NSX Edges that have been designated to carry their traffic.

A logical switch in the NSX model maps to a NIC network segment in the BMC Network Automation PCM model. A network container in PCM therefore encapsulates the set of logical switches associated with its NIC network segments, and the NSX Edge instances they connect to. Logical switch names used in the Deploy Logical Switch custom action of the configureActionInfoBlueprint container blueprint schema of type customActionInfoBlueprint must follow the naming convention of ${containerName}-nicSegmentName.

When you create a logical switch in NSX, it automatically creates a port group in the dvSwitch associated with it. NSX names the port group as vxw-dvs-dvsID-virtualwire-logicalSwitchID-sid-vxlanID-logicalSwitchName. These IDs are not known to the BMC Network Automation PCM model, and must be discovered at run time. You can use the NSX Discover Port Group custom action to discover these IDs. You can use the results of the custom action to populate the port type nameWithinSwitch attribute in the PCM model. The hypervisor switch owning the port type will correspond to the dvSwitch. However, BMC Network Automation will not attempt to communicate with the dvSwitch directly when configuring the container. Instead, it will communicate with the NSX Manager to create the logical switches, and the NSX Manager automatically creates the port groups on the dvSwitch.

NSX manages the acquisition of VXLAN IDs for its logical switches internally through its own VXLAN pool. BMC Network Automation cannot use a pool in a pod to manage them. Therefore, for the NIC segments within an NSX container, its VLAN is represented as null, and its values are not managed by BMC Network Automation.

BMC Network Automation and BMC Cloud Lifecycle Management support east-west firewalling through the NSX global firewall rules. However, those rules in NSX can be modeled only when they are applied to a particular logical switch. If they are applied to other entities, such as hosts, clusters, datacenters, VM attributes, they cannot be modeled. Therefore, you must apply the NSX global rules always to logical switches. Further, note that a given section within the global rules corresponds to a particular NSX distributed firewall device in BMC Network Automation, where the section name corresponds to the security context name of that device. Therefore, a given distributed firewall in an NSX container should only manage a single interface (with an inbound ACL), which services the NIC segment associated with the logical switch which its global rules section are applied to.

Container blueprint requirements

Before importing a container blueprint, ensure that the following requirements are met:

• Custom actions for NSX in the Switch Port Provisioning and VMware NSX Management groups are in an enabled state. In the BMC Network Automation UI, navigate to Admin > Device Adapters > Custom Actions > Switch Port Provisioning or VMware NSX Management to enable these custom actions.
• Make sure the container blueprint templates are added to the system before importing container blueprints.

_{Back to top}

Provisioning sequence

The following sequence of actions are executed when an NSX container is provisioned:

Topology of a sample NSX container with distributed firewall

Container creation involves deployment of various NSX components such as logical switches, Edge service gateways, and distributed routers. It also involves configuration of Edge service gateway and distributed router uplinks, internal interfaces, and routing. The following network diagram depicts a sample NSX container with distributed firewall.

As shown in the network diagram, an Edge service gateway gets deployed with one uplink interface and two internal interfaces. The uplink interface of Edge service gateway is attached to an external network. An internal interface is attached to the management network port group and is configured with the management IP address. Other internal interface is connected to a logical switch created for bridging between the Edge service gateway and distributed router. Similarly, distributed router is deployed with the uplink interface connected to the bridge logical switch and has internal interfaces connected to the customer networks through logical switches. Depending on the customer networks, number of internal interfaces might vary. In case of a container with distributed firewall, the firewall filters east-west traffic. OSPF dynamic routing is being used for the traffic across all the components.

_{Back to top}

ACL updates

When an ACL update occurs on a distributed firewall in an NSX container, and BMC Network Automation pushes firewall rules (through an injection template created at run time) to the corresponding section within the NSX global rules, BMC Network Automation attempts to reuse the existing NSX global IP Set instances for the source and destination address and subnet values involved. Also, BMC Network Automation attempts to reuse the existing NSX global Application instances for destination port and range values involved. When existing instances are not available, new ones are created at run time within the injection template, named using a prefix of "sectionName:“, and a suffix that identifies the IP Set or Application instance involved. Such newly created instances exist until the firewall is deprovisioned.

For example, if the section name is MyContainer-MyVfw, and you are adding an IP Set for the host address “1.0.0.1”, the new instance would be named MyContainer-MyVfw:1.0.0.1. If you are adding an IP Set for the subnet “1.0.0.0/24”, the new instance would be named MyContainer-MyVfw:1.0.0.0/24.

If you are adding an Application for the TCP port 80, the new instance would be named MyContainer-MyVfw:TCP:80. If you are instead adding an Application for the TCP port range 7000-7010, the new instance would be named MyContainer-MyVfw:TCP:7000-7010.

Sample pod and container blueprints

You can find sample pod and container blueprints and related templates in the BCAN_HOME\public\bmc\bca-networks\csm\samples\sampleWithNSX directory on the BMC Network Automation application server. The directory contains two types of blueprints: blueprints with firewalls and bronze blueprints without firewalls. 

See Pod-model and Container-model for additional information about the sample pod and container blueprints for use with NSX.

_{Back to top}