Policy Engine

Feature Description


Policy Engine is a feature allowing objects such as Security Groups and IP Sets to match across NSX Managers. Policies can be defined for up to 12 destination NSX Managers. Policy Engine can synchronize / copy security objects from disparate NSX domains as a migration strategy or ongoing synchronization for non-Federated NSX domains / cloud SDDCs.

Minimum Release: 3.1 
Application: NSX-v, NSX-T, VMCoAWS.  
License: Enterprise 
Privilege level: Audit (viewing), Operations role or higher (created/edit policy)

Setup


A Policy is defined by configuring source and destination NSX Managers and criteria. To create a policy, navigate to the global policy dashboard under Tools > Policy Sync. All policies, if configured, for all NSX Manager Data Sources will be shown on this page.

Add a New Policy


To create a new policy, click the green plus sign under Policies to get started. A window will appear to define the policy base characteristics such as Name, Description, Type and Interval.

Supported synchronizations include Security Groups, IP Sets, VM Tags, Security Tags and dFW rules/sections. Please refer to the release notes to see which are supported in your version.

Scenario: Source Security Groups contain static VMs. Upon synchronization, if the destination does not have matching VMs (by name), ReSTNSX will insert the source VM’s IPs into the destination Security Group.

Scenario: Source Security Groups contain Segments. Upon synchronization, if the destination does not have a matching Segment (by name), ReSTNSX will insert the source segment subnet(s).

Interval is defined as minutes between running a synchronization. The minimum interval is 1 minute.

In this example, a new policy called My Daily Sync is created to synchronize Security Groups once a day (every 1,440 minutes).

Based upon your ReSTNSX release, the policy type may be Security Group, IP Set or dFW Section. Please refer to the release notes for your version for supported options.

Once the base policy information is saved, expand the new policy and the source and destination NSX Managers by clicking on the green plus arrow under Policies.

For each NSX Manager, add definitions for the source and destination criteria.

This example shows a one way synchronization (push) from NSX Manager 172.16.100.232 to NSX Manager 172.16.100.36 for a Security Group named My IP Set1 to denote IP Sets will be used to synch. The arrows under Destination can be toggled to change the direction of the synchronization.

Beginning in v3.4, Palo Alto is an available source. This is a pull-model only where ReSTNSX will read the Address Group(s) to synchronize their members to select NSX IP Set(s).
Source and Destination Security Groups may be existing or if you wish ReSTNSX to create them, select “Create New” from the drop-down and enter a name for each side to be used.
Object names for the source and destination criteria do not need to match. For example, the source Security Group name could be “Security Group1” and the destination Security Group have the name “Security Group2”
Policies are disabled by default. Click the Enable slider on the policy to start the timer. Additionally, you can manually start the synchronization by clicking the blue circular arrows to the left of the Policy Name

Once the desired settings are made, Security Group criteria will need to be defined. Since we are doing a push only, the source Security Group – My IP Set1 – will need members. This example shows adding two VMs – photon-vm-1 and photon-vm-2 with IP Addressing 172.16.100.222 and 172.16.100.223, respectively.

Validate the members were added and query to validate their IP Addresses on the source manager.

The destination NSX Manager had the Security Group created with no members. The members will be added once the policy is enabled and executed.

The destination Security Group does not yet have any direct or effective members.

Starting the Policy Synchronization


Once policy is saved and enabled, the timer begins. In this example, we can wait 1,440 minutes or override with a manual synchronization. To do so, click the blue circular arrows to the left of the Policy Name. This will immediately push the respective changes to each NSX Manager.

After the initial run, the history window reflects all updates that were made across all policy members. In this example, we see that 172.16.100.36 has been updated with the effective members of the My IP Set1 Security Group that was sourced from 172.16.100.232

If the source or destination member IP Sets were deleted between scheduled runs, ReSTNSX will re-create them and then synchronize.

To validate the members were pushed, switch to the destination NSX Manager – 172.16.100.36 – and validate the Security Group members and IP Set contents.

Within the Security Group, a new IP Set was dynamically added during the synch. In this example, the source NSX Manager is appended to the object name for easy identification.

Confirm the contents of the destination IP Set where the VM IPs were added.

The result is that the source and destination Security Groups are now, and will be every day, be in synch. As a result, any dFW or eFW criteria where these Security Groups are referenced will be synchronized.

If the Policy is of type IP Set (not a Security Group member, but rather a standalone object to be synchronized), the IP Set contents are replaced, not updated. As a result, IP Sets that are receiving updates are overwritten to match the source. If a user updates the destination IP Set, it will be overwritten the next time Policy Sync runs.

Deleting a Policy


To delete a policy, select the red x to the left of the policy name. If ReSTNSX created the objects during synchronization, the user is prompted an option to delete the associated objects. In our example, the two IP Sets – My IPSet 1 – 172.16.100.232 and .36 would be deleted.

Was this article helpful?
Dislike 0
Views: 149