Configure the NSX integration

Introduction to the NSX integration

Abiquo offers support for NSX-V with blueprints for:

• NAT

• Gateway

• ECMP

And Abiquo offers support NSX-T, see Abiquo and NSX-T and Configure the Abiquo NSX-T integration

Supported versions

• See VMware

• To use the firewall and load balancer functionality, NSX Advanced edition or higher is required.

Requirements

• Abiquo supports only one vCenter when working with NSX-V

• You will need a vCenter user with NSX-V administrator rights to use it from Abiquo.

• Ensure the vCenter is managing all hosts so NSX-V can use vCenter to manage them.
  If there are unregistered hosts, the plugin will not work. Abiquo does not validate this.

• Each NSX-V blueprint requires a separate Abiquo license.

Limitations

• Chef is not supported because the NSX-V DHCP does not support the required vendor-encapsulated-options.

• Load balancers are only available through the NSX-V Gateway blueprint and the NAT blueprint

• Abiquo does not currently support firewalls applied to load balancers.

Recommendations

• We recommend using a cluster not managed by Abiquo to deploy the Edge appliances. This cluster is defined in the Remote Services appliance properties in each DC.

Configure the integration

To configure the integration

1. Use the tool supplied by Abiquo to get the values of the NSX configuration properties from the vCenter. 

   • Later you can also use this tool to check that the Abiquo properties are properly configured.

2. Follow the specific steps for the chosen blueprint as described in the guides below:

   • NSX gateway configuration guide

   • NSX with ECMP configuration guide

   • NSX NAT configuration guide

   In a nutshell, you will need to perform the steps below:

   1. Set the NSX global properties and the enterprise defaults in the Remote Services properties.

   2. Set the NSX enterprise properties in Abiquo as necessary.

   3. In Abiquo, create the NSX devices for the configured plugin type. The endpoint will usually be something like  https://ADDRESS/api, where ADDRESS is the NSX appliance IP address. See Manage devices

Integration details

The following sections describe the integration, but you should also see the documentation for individual elements, such as firewalls and load balancers.

NSX synchronization

It is not necessary to synchronize the NSX integration elements. Abiquo synchronization in NSX only applies to configurations that conform to Abiquo specifications with 1 x routing rule, identifier in comment field, and so on.

NSX firewalls

Firewall in NSX with Abiquo works like this:

• If there is no firewall on a VM, all traffic is allowed by default. Otherwise, all traffic is denied by default.

• Abiquo creates global firewall rules and applies them to logical switches, and then specifies individual VM

  • Global firewall rules are identified by the names of the firewall and the VDC.

  • Firewalls apply to the logical switch, not to NICs (The NSX API does not expose methods to access the ESXi API to obtain vNIC details)

  • Traffic through all logical switches is filtered by the firewall

• Rules are always evaluated in order

  • Rules apply globally to all VMs connected to the same logical switch, even to those that don't have the firewall assigned.
    Abiquo configures the source and destination IPs so as to guarantee the rules will only apply to the right VM

• Abiquo creates a global firewall rule section with the VM name

• Abiquo creates rules as IN or OUT with origin or destination IP as appropriate

• Abiquo creates rules for each IP

See Manage firewalls  for further details.

NSX load balancers

Load balancers in NSX with Abiquo work like this:

1. Abiquo does not support firewalls assigned to load balancers. By default, Abiquo will explicitly permit traffic to virtual servers.

2. Load balancers can have private and public IP addresses. These IPs will be taken from the range reserved by properties.

3. A virtual LB will be created for each routing rule and each load balancer address.

4. The platform only allows one routing rule to limit problems identifying load balancers in synchronization.
   You can use multiple load balancers for incoming traffic to multiple ports

See Manage load balancers for further details.

External and public networks

With the NSX integrations, External and Public networks are logical switches defined in the NSX manager.

To enable users to work with external and public networks in the Abiquo NSX integration, follow the steps below:

1. Create external and public networks in the NSX manager

2. Create the same networks in Abiquo. On the Create network dialog:

   1. Select the NSX device pointing to the corresponding NSX manager as Device.

   2. Use the Segment ID for the network logical switch as Tag.

DHCP

VMs must have port udp/68 open for DHCP to work. By default, Abiquo will create a default inbound rule for it when creating a firewall.

For the NAT plugin, the platform configures the same gateway for all vNICs of a VM (through the Edge / DHCP / static bindings). For the ECMP plugin, the platform only configures the default gateway in DHCP for the first vNIC.

For private networks, Abiquo will manage DHCP through the provisioned NSX appliances during VDC creation:

• In the Gateway blueprint, the NSX edge acts as the DHCP server for the VMs, and has a DHCP static binding for each VM IP address.

• In the ECMP blueprint, the DHCP server is at the same level as the DLR

For External/Public networks, Abiquo will search for an Edge appliance on the network logical switch with DHCP enabled. Otherwise, it will fallback to the DHCP configured in the DC Remote Services. In this case, Abiquo will not validate whether the DHCP requests/replies are properly forwarded from the DHCP server to the logical switch.

Custom private network gateway

When working with NSX (using NAT or ECMP configurations), the platform creates an Edge for each virtual datacenter to provide gateway, DHCP, load balancing, and so on.

Static Edge gateway configuration VM

This configuration is with the default settings, which means the nsx.static-edge-gateway property is set to true.

To use your own network security software deployed on a VM and direct all virtual datacenter traffic through this VM, create your own custom gateway in a private network.

1. Create your VM to use as a gateway 

2. Configure the VM to add NICs in the private network, and a public network or similar

3. Edit the private network and set the address of your gateway VM as the network gateway

4. Deploy the VM

The platform updates the existing leases in the NSX Edge DHCP to use the new gateway IP, and all new leases will use it too.

The platform updates the Private Network IP on the NIC of the Edge to the new gateway IP.

Non-static Edge gateway VM

This is with the nsx.static-edge-gateway property set to false.

To use your own network security software deployed on a VM and direct all virtual datacenter traffic through this VM, create your own custom gateway in a private network.

1. Create your VM to use as a gateway 

2. Configure the VM to add NICs in the private network, and a public network or similar

3. Deploy the VM

4. Edit the private network and set the address of your gateway VM as the network gateway

The platform updates the existing leases in the NSX Edge DHCP to use the new gateway IP, and all new leases will use it too.

The platform does not update the Private Network IP on the NIC of the Edge.

Change the private network IP of the Edge

To change the private network IP of the Edge

1. Edit the private network and for the Gateway, set an IP that is not in use (i.e. not assigned to any VM, with no DHCP lease). 

2. The platform updates the DHCP and it updates the Private Network IP on the NIC of the Edge to the new Gateway IP.