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. 

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.

Custom actionDescription
Switch Port Provisioning custom action group
NSX Delete Logical SwitchDeletes a logical switch.
NSX Deploy Logical SwitchDeploys a logical switch.
NSX Discover Port GroupDiscovers the name of the port group which is associated with a logical switch in NSX. The full name of port group contains the logical switch name, dvSwitch name, Virtual Extensible LAN (VXLAN) ID, and datacenter name.
VMware NSX Management custom action group
NSX Add Interface to Edge Device (Distributed Router/Service Gateway)

Adds interface to an NSX Edge device and attaches it to the network.

NSX Delete Edge Device (Distributed Router/Service Gateway)Delete an NSX Edge device.
NSX Delete Interface from Edge Device (Distributed Router/Service Gateway)Deletes interface from an NSX Edge device.
NSX Deploy Edge as Distributed RouterDeploys NSX Edge device as a distributed router with one uplink interface connected to the bridge network.
NSX Deploy Edge as Service GatewayDeploys NSX Edge device as service gateway with one internal interface as management network, other internal interface for bridge network (bridging between service gateway and distributed router), and one uplink interface for external network.

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 nodeNode typeDevice type of the host device
    EdgeGatewayHostVanillaVMware NSX Manager
    DistrbutedRouterHostVanillaVMware NSX Manager
    DistributedFirewallHost FirewallVMWare NSX Distributed Firewall with Admin as the security context
    AccessHypervisor SwitchVMware vSwitch
  • Gather the values for the following attributes that you need to provide during pod creation: 

    AttributeSteps to gather the value
    datacenterID
    1. Browse to the following link: https://vCenterIP/mob.
    2. Look for the content property and click the content hyperlink in the VALUE column.
    3. Look for rootFolder and click the group-d<suffix> hyperlink.
    4. Look for childEntity. Record its value as the datacenterID.

      In this example, datacenter-2 is the datacenterID.
    datastoreID
    1. Click the datacenter ID (datacenter-2) that you obtained in a previous step.
    2. Look for datastore. Record its value as the datastoreID.

      In this example, datastore-10 is the datastoreID.
    resourcePoolID
    1. Click the datacenter ID (datacenter-2) that you obtained in a previous step.
    2. Look for hostFolder. In its value, click the group-h<suffix> hyperlink.
    3. Look for childEntity. Its value shows the clusters.
    4. Click the required cluster hyperlink.
    5. Look for resourcePool. Record its value as the resourcePoolID.

      In this example, resgroup-49 is the resourcePoolID.
    Port Group Object IDs
    1. Click the required cluster hyperlink (domain-c48) that you obtained in a previous step.
    2. 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
    1. Run the following GET REST API call using any of the REST clients:

      https://NSX-Manager-IP/api/2.0/vdn/scopes

    2. 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.

Note

VXLANs are also called segments and logical switches are also called virtual wires.

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 timeYou 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.

Note

The NSX Service Gateway can perform perimeter (north-south) firewalling and load balancing in addition to routing. However, BMC Network Automation and BMC Cloud Lifecycle Management do not support these services yet. You can use other supported non-NSX firewalls to secure the perimeter of your container.

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:

StepTarget deviceActionDescription
1EdgeGatewayHost node NSX Deploy Logical SwitchDeploys logical switch for the bridge network, which is used to connect Edge service gateway and distributed router.
2EdgeGatewayHost node NSX Deploy Edge as Service GatewayDeploys an NSX Edge device as a service gateway.
3EdgeGatewayHost node NSX Deploy Edge as Distributed RouterDeploys an NSX Edge device as a distributed router.
4DistributedRouterHost nodeNSX Deploy Logical SwitchDeploys logical switch for the enabled customer NIC segment.
5DistributedRouterHost node
NSX Discover Port GroupDiscovers exact name of the port group created in dvSwitch in vCenter as a result of deploying logical switch for the NIC Segment. Since NSX adds extra information to the port group name, such as VXLAN and dvSwitch name, apart from the logical switch name, BMC Network Automation needs to discover it and populate it to the nameWithinSwitch attribute of the PortType blueprint of the NIC Segment under the Access switch node.
6DistributedRouterHost nodeNSX Add Interface to Edge Device (Distributed Router/Service Gateway)Adds internal interface to the Distributed Router Edge device and attaches it to the logical switch created for the NIC Segment.
7DistributedFirewallHost nodeDeploy to ActiveCreates new section dedicated for the Distributed Firewall Guest created on this host node.
8guest node of the EdgeGatewayHost nodeDeploy to Active

Configures Open Shortest Path First (OSPF) routing on the Edge gateway device. In case of Edge service gateway, the internal bridge interface is configured as OSPF interface.

9guest node of the DistributedRouterHost nodeDeploy to ActiveConfigures OSPF routing on the Edge distributed router device. In case of distributed router, the uplink bride interface is created as OSPF interface.

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

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

Comments