NSXT DFW V2T migration - part 2

Since I put a lot of information into my session, I decided to split the information into 3 smaller blog posts. When the recorded session becomes available, I will update this blog with a direct link.

1. Introduction (link)

2. DFW objects (current blog)

3. Edge migration (link)

Updated March 2022 : The VMUG NL session can be viewed here and this is the direct link to my session.

Information on Host Migration, as discussed in my VMUG session, can be found in these previous NSX V2T migration blog posts:

• NSX V2T DFW only migration part one

• NSX V2T DFW only migration part two

• NSX-T move a security policy after V2T migration

• NSX-T copy a security policy using PowerCli

Okay, so much for the introduction. Let’s get started.

NSX V2T DFW Objects

For the presentation I performed a V2T migration in our lab environment. To be able to demonstrate some of the issues I encountered during previous V2T migration I also created several firewall rules in the NSX-V environment. These rules are not exact copies of the rules I found, but are examples to show some of the issues I encountered.

Once the NSX-V configuration is imported and analysed. The migration coordinator will list the issues found in the Distributed Firewall configuration that can’t be directly migrated to NSX-T. The only option is to 'skip' these. Which isn’t an option to most NSX-V users. The only option is to cancel the migration and change the Distributed Firewall configuration so that it can be migrated.

A handy method of exporting the results can be found here V2T migration analysis.

DFW Objects

Besides vSphere, NSX-T can also be used on KVM hosts. Therefore, the option to use vCenter objects in the Distributed Firewall isn’t available anymore in NSX-T. A detailed list of the available features supported by the migration coordinator can be found here.

vSphere Objects

The Datacenter object is one of the objects that is used in firewall rules. This because it represents all the virtual machines in the environment. It is a dynamic group that automatically includes new VM’s when they are added to the vSphere Datacenter.

The Datacenter object is mostly used if physical devices are also using the same IP-space as virtual machines. With this object the physical devices are automatically excluded from this group.

The method of changing this group depends on the place where the group is used in the Distributed Firewall configuration.

If it is used in the Source of Destination of the firewall rule it can be changed into an IP-set just before the migration. After the migration the NSX-T Segments can be added to the group, to make it dynamic again. The only downside is that new NSX-T Segments aren’t automatically added to the Security Group. Take this into consideration when creating new Segments.

Sometimes the group containing the vSphere Datacenter object is also used on the Applied To part of the Firewall rules. If it is used in the Applied To, replacing it by an IP-set will not work. Since firewall rules can’t be applied on IP-sets.

The reason why the vSphere Datacenter object is used in the Applied to, is because a lot of people mentioned repeatedly to always use the Applied To field (myself included). But applying a firewall rule to the entire datacenter is the same as applying it to the complete Distributed Firewall. So, for this use-case the Applied To field can be set to Distributed Firewall.

Distributed Virtual Portgroup

Like the vSphere Datacenter object, a Distributed Virtual Portgroup (DVPG) also cannot be migrated directly into NSX-T using the migration coordinator in version 3.1. Although you might think these are translated to a segment that is created in NSX-T, this is not the case. Again, the method changing these objects depends on where they are used. If they are used in the Source and destination, the Segment can be replaced by an IP-set.

If a DVPG is used in the Applied to an option can be to add the virtual machines or logical ports of the machines directly into the group.

Excluded members

Another NSX-V Distributed Firewall feature that can’t be migrated is the option to exclude members from a Security group. In this example I’m showing a method of creating a Security group for the internet.

Of course, the internet can also be represented by an IP-set, but sometimes that's harder to maintain than using this method. Especially when public IP-addresses need to be excluded from the group. In this example the group has been built by adding an IP-set for 0.0.0.0/0 to a Security group. Then the IP-sets for APIPA, RFC 1918, Multicast and the public IP-addresses for the customer are excluded.

This solution, for adjusting this group so it can be migrated, is shown in the Effective Members part of the Security group. Here a list of the effective IP-sets that can be directly copied, to create a separate IP-set. Which can replace the current included and excluded members of the group.

Grouping objects

The last example I showed in my presentation was related to grouping methods. In NSX-V there are many methods of grouping items into Security groups. Some of them can have a huge impact on the CPU usage of the NSX-V manager, because they need to be calculated every time the group membership changes. Therefore we want to avoid using regex functions in dynamic groups. On several occasions I saw 'Entity Belongs to' being used to create dynamic groups based on tags. Some of those methods could not be translated to NSX-T, prior to NSX-T 3.1.3.3. One of those methods is using the (AND) function in combination with 'Entity Belongs to'.

For example, the following method cannot be translated, prior to NSX-T 3.1.3.3.

This method can be translated to the following groups if you are migrating to an old version.

Although I didn’t receive an error in my lab for these type of grouping objects, my lab was built with NSX-T version 3.1.3.3. I still encountered them in an environment where I had already deployed an NSX-T manager and upgraded it to version 3.1.3.3.

Migrate Configuration

Once al issues have been resolved the NSX-V configuration can be imported and analysed again in the NSX-T migration coordinator. After all items have been resolved the migration can then be created into the NSX-T manager, using the Migrate Configuration step.

When the Migrate Configuration step is complete all the firewall rules should be present in NSX-T. It may be smart to verify at least a few important firewall rules, just to make sure they have been created as expected.

That is it for now. In the next blog I’ll go over the Edge migration steps in the V2T migration.

Thanks for reading and hopefully this was helpful.