Considerations When Using Layer 2 Bridges for NSX-V to NSX-T Migration
I recently had a customer who asked for some general feedback on their high-level plan to migrate from NSX-V to NSX-T using layer 2 bridges. Although every environment is different and the details of migration procedures should be tailored to each environment, I thought I’d share the general guidance I gave to this customer in case there are some points here that may be transferrable to other similar NSX-V to NSX-T migration plans.
Migration Plan Overview
- Deploy a greenfield NSX-T environment.
- Configure layer-2 bridges in both NSX-V and NSX-T environments.
- Migrate workloads to NSX-T environment.
- Decomission NSX-V environment & remove L2 bridges in NSX-T environment.
Ensure that layer 2 bridge instances in both NSX-V and NSX-T enviroments are able to handle expected traffic flow.
- In NSX-V, bridging instance gets enabled on the ESXi host where NSX-V DLR control VM is running; if multiple sets of layer 2 bridging instances are needed, try to spread bridging load across different ESXi hosts.
- In NSX-T, consider deploying NSX-T edge node VMs dedicated to bridging.
- Create redundancy in layer 2 bridges in both NSX-V and NSX-T environments.
- Estimate the downtime required for the network cutover from changing the default gateways after workloads are migrated to the NSX-T environment.
Ensure the distributed firewall rules and security constructs in NSX-V that are in use can be applied in NSX-T.
- NSX-T DFWs cannot use vCenter objects; IP sets work in both NSX-V and NSX-T – consider changing all the security constructs to IP sets for the migration.
- If you are using security tags, they must be reapplied to the VMs after vMotion to NSX-T.
- When migrating the DFW rules, consider using scripting/APIs since NSX-V DFW is in XML and NSX-T DFW is in JSON or do it manually.
NSX-T Layer 2 Bridging Requirements
- Keep in mind that Layer 2 bridging requires allow forged transmit, MAC learning, and Virtual Guest Tagging (VGT). Refer to the official documentation for more details.
- Design the future state NSX-T architecture so that it is flexible enough to support temporary layer 2 bridges during the migration (i.e. N-VDS design, edge node sizing, etc.).
Sequence of Events
The steps in the detailed plan should be carefully sequenced to ensure success of the migration plan.
- Ensure NSX-T T1 router and NSX-V DLR are not using the same MAC address - instantiate NSX-T T1 router with a different MAC address by creating a transport zone with an API call, setting “nested=true”. Refer to the official NSX-T API guide for details.
- To minimize or eliminate any bridged traffic, prioritize the workloads to be migrated and keep highly interactive application VMs together on the same site where possible (i.e. App and DB).
- Consider migrating subnet by subnet so that each time an entire subnet is moved, the default gateway can be changed from NSX-V ESG to NSX-T T1 router.
- Set up and test NSX-T environment before starting the migration.