NSX Distributed Firewall Sections and Rules via APIs

When you have to create multiple Distributed Firewall Rules, it could be very helpful to leverage NSX APIs.
It could be even more helpful to create different DFW Sections to logically separate different Tenants.

The maximum number of sections you can create under a single NSX Manager is 10,000.
The maximum number of Firewall Rules you can create per NSX Manager is 100,000.

vCloud Director 8.20, thanks to the new NSX integration, enables the configuration of Micro-Segmentation configuration on a per Tenant, per Organization Virtual DataCenter basis.
Distributed Firewall configuration is managed in the scope of every single vDC (note: DFW must be enabled on the vDC by a System Administrator).
In NSX Manager, a different Section is created for every vDC when Distributed Firewall has been enabled.

When you want to leverage the APIs to interact with the Distributed Firewall, you must obtain the Etag for the object you need to modify.
Etag stands for Entity tag and it is an identifier for a specific version of a resource. It’s used like a fingerprint to be sure that the representation of an object is not changed since the last interaction with it.

Following some examples of API interaction with DFW Sections.

  1. Firewall Section Creation
    POST https://NSX-MANAGER/api/4.0/firewall/globalroot-0/config/layer3sections –header ‘Content-Type:text/xml’Body
    <section name=”TestSection”>

    </section>

    The Response Header contains Etag and Location of the new object (the DFW Section) to be used for future changes.
    etag
    Location URL will be used when we’ll modify the created Section (rename it or create/modify Firewall rules under it).

  2. Firewall Section rename (optional, it will modify the Etag)
    PUT https://NSX-MANAGER/api/4.0/firewall/globalroot-0/config/layer3sections/1006 –header ‘Content-Type:text/xml’ –header ‘if-match:”1495902005576″
    if-match makes the API call conditional, it’s only considered valid if the Etag passed in the call is equal to the one cached on the Server if the object has not changed in the meantime.Body
    <section name=”TestSectionRenamed”>

    </section>

     

    Result: the previously created Section has been renamed to TestSectionRenamed.
    TestSectionRenamed
    The new Etag is in the Response Header.
    newEtag

  3. Creation of a new Firewall rule in the created Section
    POST https://NSX-MANAGER/api/4.0/firewall/globalroot-0/config/layer3sections/1006/rules –header ‘Content-Type:text/xml’ –header ‘if-match:”1495902401161″
    Remember to always use the last generated Etag.

    Body
    <rule disabled=”false” logged=”true”>
    <name>Test-Rule</name>
    <action>ALLOW</action>
    <sources excluded=”false”>
    <source>
    <value>10.112.1.1</value>
    <type>Ipv4Address</type>
    <isValid>true</isValid>
    </source>
    </sources>
    <services>
    <service>
    <destinationPort>80</destinationPort>
    <protocol>6</protocol>
    <subProtocol>6</subProtocol>
    </service>
    </services>
    </rule>

    In the Response Header you can find the Location of the new object (the Firewall Rule) and the new Etag to be used for future changes.
    Location

  4. Firewall Rule change
    GET https://NSX-MANAGER/api/4.0/firewall/globalroot-0/config/layer3sections/1006
    The Response Header contains the Etag to be used to modify the rule.
    If no changes happened since last change, it will be the same you can see in the screenshot at point 3).You can modify the DFW rule with the following call, using the object Location URL obtained before.
    PUT https://NSX-MANAGER/api/4.0/firewall/globalroot-0/config/layer3sections/1006/rules/1007 –header ‘Content-Type:text/xml’ –header ‘if-match:” 1495903193596″

    Body
    <rule disabled=”false” logged=”true”>

    <name>Test-Rule-Renamed</name>
    <action>allow</action>
    <appliedToList>
    <appliedTo>
    <name>DISTRIBUTED_FIREWALL</name>
    <value>DISTRIBUTED_FIREWALL</value>
    <type>DISTRIBUTED_FIREWALL</type>
    <isValid>true</isValid>
    </appliedTo>
    </appliedToList>

    <sources excluded=”false”>
    <source>
    <value>10.112.1.1</value>
    <type>Ipv4Address</type>
    <isValid>true</isValid>
    </source>
    </sources>
    <services>
    <service>
    <isValid>true</isValid>
    <destinationPort>8080</destinationPort>
    <protocol>6</protocol>
    <subProtocol>6</subProtocol>
    <protocolName>TCP</protocolName>
    </service>
    </services>
    <direction>inout</direction>
    <packetType>any</packetType>
    </rule>

    Here’s the modified rule:
    Rename-rule

    The new Etag to be used is in the Response Header:
    Last_Etag

    If you try to modify the FW rule using the wrong Etag, you get the following error:
    Error_wrong_Etag

You can find the full NSX API documentation at the following link:
https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.3/nsx_63_api.pdf

 

vCloud Availability for vCloud Director 1.0.1.2

On July, 13th VMware has released version 1.0.1.2 of vCloud Availability for vCloud Director.
Here you can find the release notes: http://tpub-stg-ic-1.eng.vmware.com:8080/Release_Notes/en/vcloud-availability-for-vcd/1012/VMware-vCloud-Availability-for-vCloud-Director-1012-Release-Notes.html
What’s new?

This release brings a new Service Manager Portal that enable a granular control of the DRaaS service with a Service Provider dedicated Dashboard.

The Service Provider Portal provides insights into:

  • Overall Resources allocation (CPU, RAM, Storage);
  • Storage consumption per Organization (Tenant);
  • Number of replications per Organization (Tenant);
  • Replication details (overall active replications, RPOs, storage consumption etc.);

Additional new features are a Reporting capability and additional management functionalities for cleanup of stale replications and migrations of failover replications to different storage.

Here’s the Login Screen of the new SP Portal:
SP-Portal

The Summary Page gives you an overview of the Service, with the overall resource allocation and utilization, list of replications, detail of Top 10 vDCs based on Storage Utilization and Number of Replications.
Summary

The Inventory tab gives you a detailed view of all the Organizations with To-Cloud Replications, From-Cloud Replications and Number of vDCs. You can select a specific Organization to drill-down and see its details.
Inventory

If you select an Organization, you can see the list of vDCs enabled for Replication and the “VM Replication Table”, the list of all replicated VMs showing the Test Recovery State, The RPO, the REcovery State and the Replication Status for every VM.
You can also filter between To.Cloud and From-Cloud replications or search for a specific VM.
vDC Detail

The Job Log Page gives you the detailed view of all the “Scrub Replication”, “Storage Migration” or Attach Storage” jobs.
You can filter by Job ID and search for specific jobs.
Job Log

What are Scrub Replication and Storage Migration jobs?
Looking at the Inventory page, you can see that every Organization has an “Action” column (gear button). Clicking on the gear pops up two possible actions, Scrub Stale Replication and Storage Migration.
Actions

Storage Migration is a wizard driven task that lets you migrate the replications to a different storage (i.e. Storage Policy).
Storage Migration

Scrub Stale Replications is also a wizard driven task that lets you cleanup the stale replications objects that may remain in place.
Scrub

Last Topic: Reporting.
Back in the Home Page you can find the link to the Report Page.
A new Report is created automatically every 12 hours by default. This is modifiable.
You can manually download a new report accessing this page.
Report