NSX-T offers federation capabilities which consolidate multiple NSX instances (locations) into a single pane of glass.
in the past VMware NSX for vSphere offered the same capabilities through the concept of universal objects: one primary NSX manager was responsible for the management of universal objects (groups and tags) and synchronized these objects with all attached (secondary) NSX managers.
One of the flaws of this concept was the global NSX security tags: The distributed firewall requires IP address information to program the distribute firewall. This information was not synchronized between NSX managers, making a universal configuration with security tags only available for active/standby scenario’s. With an active/active scenario the only available option was to use universal IPset objects, which only contained static IP addresses.
NSX-T Federation used another concept where the NSX security tags are still local to a NSX manager instance, but the NSX security group information is shared with all applicable locations (NSX management cluster instances) and therefor suitable for active/active scenario’s.
Local NSX security tags.
The difficulty of using global security tags lies in translating a VM object into a usable IP address, the DFW uses the IP addresses to program the distributed firewall. This translation can only be achieved by the NSX Manager which is directly connected to the vCenter server or has direct control of the attached segment.
The preferred method of translating a VM object to an IP address is by using VMware Tools, which is installed on the guest OS of a VM. VMware Tools tells the vCenter server which IP addresses are configured, this enables the (local) NSX-T Manager to reads these IP addresses directly, which are sequentially programmed by the distributed firewall.
The other methods is using ARP/DHCP snooping, were the NSX Manager listens on the segment for IP address information. This last method tends to be more resource intensive.
As the global NSX Manager does not have a direct connection to either the vCenter or a segment, it cannot translate the VM object to IP address for distributed firewall programming.
On the global NSX manager there is no possibility to manage containers, virtual machines, physical servers and tags. These operations can only be executed on local NSX managers. See the difference between the available options at the inventory overview pane for both the local and global NSX Managers in the picture below
Global NSX Security groups
Now you know that security tags are local objects, NSX federation offers grouping capabilities to tie those local security tag object from different locations together into a single global group by syncing IP address information within a region.
Group objects which are created on the global NSX Manager are provisioned on the local NSX Managers, but are identifiable by the (GM) icon after the group name.
The “Membership Criteria” option of a group objects enables you to define dynamic grouping functionality which span multiple locations. The security tag name is the unique identifier and can therefor identify virtual machines from multiple locations.
The “effective members” of a group shows you which virtual machines, IP addresses, segments, segment ports and VIF are included. Which information is available depends on the NSX manager to which you are logged into.
The global NSX Manager only has IP address information available, as this is the only piece of information that is being synced between locations (shown on the right). Again the global NSX manager cannot manage virtual machines, containers, segments and therefor no information about these objects is visible and is shown as (0) objects.
As a local NSX manager only have access to more information for its particular location, it can show you more specific information (show on the left). Again this is location specific information: only the IP address information is synced between locations.
Regions
NSX federation offers flexibility by utilizing a concept which enables you to define regions. A region include one or more locations, but a location can belong to one or more regions.
So in the scenario were you have 3 location, all locations are included in a global region. You can manually define a region A which includes location 1 and 2, and a region B which includes location 2 and 3. In this case location 2 belongs to the global region, region A and region B
Which regions are applicable for the group, depends on its configured scope.
