NSX-T Bridge for V2T migration

The NSX-T Layer-2 bridge primary use is to connect an overlay segment to a VLAN-backed portgroup. This makes the Layer-2 bridge very useful in migration scenarios from a VLAN backed portgroup to an NSX-V logical switch or an NSX-T segment.

The Layer-2 bridge was implemented on the Control VM in NSX-V resulting in very slow throughput (less than 1 Gbps). For NSX-T VMware has built the Layer-2 bridge in an edge cluster giving it much better throughput of several Gbps. The throughput is now more depending on the configuration and the load on the ESXi host.

Because the NSX-T Layer-2 bridge is built in an edge VM, that edge VM can also be deployed on hosts that are not prepared with NSX-T. For example, an NSX-V prepared host. If the edge VM is deployed on an NSX-V prepared host it can be connected to a VXLAN-backed portgroup. Thus, building a Layer-2 bridge between the NSX-V and the NSX-T overlay. Or between VXLAN and GENEVE if you like. In this set-up the edge or bridge looks something like this

In NSX-T 3.1 VMware documented this option in the Migration Coordinator guide.

Something that is now well documented in the Migration Coordinator guide is the fact that you need to change the default MAC address of the NSX-T virtual distributed router. Because by default the NSX-V Distributed Logical Router (DLR) and the NSX-T virtual distributed router use the same MAC address for the gateway. I’ll show you the procedure that is documented in the Lift and Shift migration option here.

So how is this NSX-T build?

Before a Layer-2 bridge can be build you need to deploy two edge VM’s on NSX-V prepared hosts. In the lab the edge is connected to a management portgroup, a portgroup with the NSX-T Transport VLAN and a portgroup to the logical switch in NSX-V we want to extend over the Layer-2 bridge.

With these edges an Edge cluster can be created. Next step is to create an Edge Bridge profile. As you can see, I only created a single edge in my lab environment. This is okay for a Proof of Concept, but the edge cluster should contain 2 Edges for production setups.

So far noting fancy. The next step is to perform some of the additional configuration required for edge-based bridging to allow the Layer-2 bridge to work. There are 3 options: promiscuous mode on the vSS/vDS portgroup, MAC learning on an NSX-T segment and configuring a port as a sink port.

In the lab I have configured promiscuous mode on the portgroup, with the following steps.

• Enable promiscuous mode and Forged transmits on the portgroup.
• Enable reverse filter on every ESXi host where the Edge VM can be running
  This can be done with a command on each ESXi host
  esxcli system settings advanced set -o /Net/ReversePathFwdCheckPromisc -i 1
• Disable promiscuous mode on the portgroup.
• Re-enable promiscuous mode on the portgroup.

After this configuration the NSX-V portgroup will look like this

Next step is to add the Edge Bridge profile to a segment.

As you can see the segment is not connected to a gateway. The Edge Bridge profile can be assigned by editing the segment and clicking on the Edge Bridges.

In the lab VLAN 0 is assigned since the edge is connected to a VXLAN logical switch. At this time the Layer-2 bridge is operational. So, a ping or other network connection should work between a VM on the NSX-V logical switch and one on the NSX-T segment with the edge bridge profile. The problem is to reach the gateway on the other side of the layer-2 bridge. This has to do with the same MAC address being used for the gateway on both NSX-V and NSX-T.

There are many methods to retrieve the MAC address of the gateway on the NSX-V side. For example, by looking in the ARP table of the DLR on an NSX-V host.

In this picture there are multiple gateways all with the MAC address 02:50:56:56:44:52. The MAC address for the NSX-T environment can be viewed in the global-config as also documented in the migration coordinator guide.

To change the MAC address on the NSX-T side the following options need to be changed using a PUT call.

• vdr_mac from 02:50:56:56:44:52 to 02:50:56:56:44:62
• allow_changing_vdr_mac_in_use from false to true

After this change has been made in the environment the gateway on the other side of the Layer-2 bridge is reachable. The change didn’t cause any network outage in the lab. For an NSX-T installation in production it should be a good practice to change this upfront. Especially if the NSX-T environment is built for a V2T migration.

When the Layer-2 bridge is completely functional it can be used to migrate (vMotion) the VM’s from NSX-V to NSX-T. This I will describe in a different blog along with some thoughts on how to migrate the security polices or firewall rules. Hopefully this blog will help you on your way to deploying and configuring the Layer-2 bridge between NSX-V and NSX-T.