According to the Gartner blog post, 2019 Network Resolution: Invest in Network Automation, the top network resolution of 2019 was network automation. This isn’t surprising since traditional automation of networking and security has always been a challenge due to the cumbersome processes, lack of governance, and limited or non-existent management tools.

Organizations that automate more than 70% of their network change activities will reduce the number of outages by at least 50% and deliver services to their business constituents 50% faster

VMware NSX-T Data Center solves this by enabling rapid provisioning of network and security resources with layered security and governance. By using various network automation tools, you can quickly and effectively keep up with the demands of your developers and application owners who expect a quick turnaround on resource requests. In this blog post we’ll look at how NSX-T Policy APIs simplifies network automation.

What Are NSX-T Policy APIs?

At the center of NSX network automation lies the single point of entry into NSX via REST APIs. Just like traditional REST APIs, NSX-T APIs support the following API verbs: GET, PATCH, POST, PUT, DELETE. The table below shows the usage:

NSX API Verbs

 

A New API Object Model

Introduced in NSX-T 2.4, the new NSX Policy APIs reduces the number of configuration steps by allowing users to describe the desired end-goal while letting the system figure out how best to achieve it. NSX-T Policy APIs provide a simplified data model and allow for consumption using an intent-based approach. The data model is based on a hierarchical tree structure shown below.

NSX-T Policy APIs Simplified Data Model

 

The hierarchical tree structure is made of strongly typed nodes and have parent/child, peer relationships with each other. Of course, this model maps easily into the RESAT APIs. Because the object model is based as a single tree, Object Names/IDs, which translates to URI and is user friendly. Users can configure the ID unlike traditional API models where the ID is system generated. This helps in accelerated development of network automation. Since objects are easily identifiable, they can be referenced without having to make a GET API call to retrieve the system generated IDs.

While NSX-T enjoys an ever growing customer base, questions like below always boil down to how good of a network automation solution you can develop:

I want to create the entire intent in one go without requiring to care about ordering or having to make multiple API calls. Can I do it?

And I would like to do it in a single API call and would like to replicate it across our dev, test, staging and production pods

The above can be applicable when you’re creating a complex routing topology with multiple Tier-1s and services or when you’re deploying various distributed firewall rules to cater to your security team’s design (or perhaps both!). The take away is you need a flexible solution that can create the entire intent in one go while realizing the objects in the right order. Correctly. The Policy APIs supports the traditional way where you can operate on each of the objects and you can perform the CURD operations, but that’s not all NSX-T Policy APIs can do.

How Does NSX Policy APIs Help?

As mentioned before, a unique ability of the NSX-T Policy API is the ability to describe the complete end-goal without having to worry about the order and dependency. Because you can define the object ID, you can describe objects which refer to other objects even if the object is not yet created!

Consider the below API:

The API creates both Tier-0 Gateway and a Tier-1 Gateway that connects to the Tier-0 just created. In just 1 API call!

A few things to note here:

  1. The API is a PATCH call with the URI as /policy/api/v1/infra. It is important to remember that while traditional API endpoints, to perform traditional CRUD operations on individual objects can be used, hierarchical Policy APIs work on the infra/ endpoint.
  2. The IDs for both Tier-0 and Tier-1 Gateways are defined in the request itself!
  3. Reference to Tier-0 in the Tier-1 object is via its path! The path follows the exact tree traversal as shows in the diagram above.
  4. Tier1 Gateway is defined first (which has a reference to Tier0 Gateway). This is completely OK!

Combine all these, and you get a simple powerful declarative model which can achieve outcomes rather than execute actions. It simplifies automation and operations.

What About Deletion? You Need to Use the DELETE Call, Right?

Well, no. The policy object model has a special flag marked_for_delete. This boolean flag can be used to delete objects in the same PATCH call as above! On top of that, you can create or edit objects and delete other objects in just 1 API call.

In the call above, the Tier1 Gateway is deleted and the display name of Tier0 Gateway is changed! In just 1 PATCH call.

The object hierarchy described above also plays a significant role in understanding the parent/child relationship. This is especially important when defining objects like Distributed Firewall Policy and Rules. I’m extending the API call above to now include a Group with dynamic member and creating a Security Policy with one Rule that uses the Group.

Just like before, I can define my own IDs, refer to objects using their path. But how did I know the path? One obvious solution is that I referred the hierarchical tree structure shown above. Based on that diagram, I can see that Groups and Security Polices are child objects of Domain. But wait, the picture isn’t complete. What about other objects that I need? What about other attributes? Well, all of that is available in the NSX-T API Guide. The allowed child objects are clearly listed out. Looking at Domain object I see the following:

Domain Child Objects: Groups and Security Polices

 

This shows that I can have ChildGroups and ChildSecurityPolicy as child objects. I can then navigate into each of them to understand their schema and use any available child objects. Its that easy! More details and information can be got from this handy Getting Started Guide on Policy APIs.

What Else Can NSX-T APIs Do?

NSX-T APIs also allow you to create complex queries to search for objects. While the feature to search was always available in the UI (and quite popular), NSX-T 3.0 adds the search API /policy/api/v1/search/query to its long list of public, supported APIs. The complete description and documentation is available in the NSX-T Rest API Guide. The search API supports an exhaustive list of resource types you can search on. The API also supports Wildcards and Boolean Operators – AND, OR, NOT. You can create simple but powerful queries like this:

 

NSX-T Policy APIs are a powerful tool to directly automate your tasks. Its easy, declarative nature allows you to create hierarchical APIs that define the entire topology in one go.

Replication through NSX-T Policy APIs

Sometimes you will need to replicate an existing configuration in a new pod or NSX deployment. In such a case, just do the following:

This returns the entire configuration. Before the response is applied to a new pod using the PATCH API, the system owned objects have to be cleaned up. Along with that, any UUIDs related to the system/fabric (like Edge UUID, Edge Cluster UUIDs or Transport Zone UUIDs)  have to be updated to reflect the new system. You can then apply it in your new pod!

Another option is you retrieve the configuration and start versioning it. This will enable you to see the changes that happened to your configuration over time and revert to any particular one. How’s that for simplifying Infrastructure as Code?

With all this, it is easy to summarize that NSX-T Policy APIs is a powerful tool for NSX-T Network Automation.

Resources