NSX-v to NSX-T workload migration with Network Coexistence via L2Bridge

NSX-v to NSX-T workload migration with Network Co-existence - L2Bridging

- Prashant Pandey , VCAP-NV

 

Use case -L2bridge is one of major use-case of workload migration from NSX-v to NSX-T along with network co-existence.

Summary - There are mainly 3 use-cases for the workload migration from NSX-v to NSX-T.

1. Subnet based Migration - Shut one subnet at NSX-v  and add & advertise the same from NSX-T

Pros - Easy to migrate, no addition VLAN requirement at physical network.

Cons – No flexibility at Application level migration, it has be entire subnet in one go, might not be feasible in most of the production environment.

 

2. Network Co-existence with VMware HCX tool – Supports Network stretch with L2E feature.

Pros – Network Co-existence can be achieved with ease.

Cons – Separate license requires, includes extra cost.

 

3. Network Co-existence with L2Bridging - Supports Network stretch with layer 2 bridging feature.

Pros – Network Co-existence can be achieved with no additional cost, with minimum physical networking requirement, that is we need a physical VLAN which can be bridged with NSX-v Logical switch & NSX-T segment.

Cons – not as such, but addition VLAN requirement at physical network, 1 VLAN per logical switch/Segment.

 

This Document is focused on the third approach i.e. Network Co-existence with L2Bridging.

 

 

 

Topology – Below is the attached diagram which we will be discussing in this document.

Physical network prerequisites & General recommendations:

·       Physical VLAN which is being used for L2Bridge (in this case VLAN-10) has to be trunked on

NSX-T as well as NSX-v hardware/ESX interfaces, where your servers/VMs & DLR (where bridging is enabled) resides.

 

·       Mapping will be one to one, that is 1 VLAN to 1 logical switch, you cannot map multiple LS to one VLAN.

 

·       Bridge instance gets created on specific ESX, where DLR resides and can be checked & verified via below 2 commands on ESX.

net-vdr --bridge -l edge-57          // (Pl. change edge id as per your environment)

net-vdr -b --mac edge-57             // (Pl. change edge id as per your environment)

 

However, if an ESX fails which contains bridge instance, NSX controller will move bridge instance to different ESX and will push a copy of MAC table to the new bridge.

 

·       Since bridging happens in a single ESX server/ Hardware. It is always recommended to use multiple DLR for multiple bridges scenario, where control VM spans to different Hardware/ESX host to improve the throughput.

NSX-v Readiness (considering base build is already completed)

 

·       Logical switch & DPG should be part of same virtual distributed switch, vDS.

·       Create logical switch, in this case Bridge-Logical-Switch (refer above topology)

·       Attach the same to DLR with LIF, in this case 10.89.208.30/27.

·       Go to DLR > Manage > Bridging

·       provide the logical switch & Distributed port group name here (Note if DPG & LS are not part of same vDS, it will not show-up here)

·       Once you publish your changes & bridging is enabled, logical-switch will reflect "Routing Enabled" option, as shown in figure.

 

 

Testing

·       TestVM01 is attached with Overlay Segment Bridge-logical-switch / NSX-T_POC-segment.

·       TestVM02 is attached with Underlay Segment of DPG-VLAN-10.

 

you may assign both machines either Bridge-logical-switch IP range (10.89.208.0/27) or DPG-VLAN-10 IP Range (10.10.10.0/28) depends on your use case, it will be reachable only.

here I have assigned overlay IPs to both machines and reachability has established.

TestVM01 - 10.89.208.1, Gateway - 10.89.208.30, Port-group: Bridge-logical-switch   

TestVM02 - 10.89.208.2, Gateway - 10.89.208.30, Port-group:  DPG-VLAN-10-L2bridge-NSX-v

 

for troubleshooting sake or to check mac learning on ESX host -you may follow below point

·       Bridge instance gets created on specific ESX, where DLR resides can be checked & verified via below 2 commands on ESX.

net-vdr --bridge -l edge-57          // (Pl. change edge id as per your environment)

net-vdr -b --mac edge-57             // (Pl. change edge id as per your environment)

 

 

NSX-T Readiness (considering base build is already completed)

 

·       Create an Edge bridge profile.

·       Create an overlay segment & save, in this case "Bridge-Segment-VL10" - No need to connect gateway & Subnet, since we are going to map this with VLAN backed segment.

 

·       edit & expend additional setting and add edge bridge profile to this segment, shown in the diagram.

 

·       Add the edge bridge profile which we created, also select the TZ as VLAN backed & Mention the VLAN id, this is the main point where you are mapping overlay segment with Underlay to make L2bridge work.

 

·       lastly we need to login to vCenter environment of NSX-T & turn on Promiscuous port & forge transmit ON for ALL-Trunk-port-group which we have used for edge nodes uplink during our base-build configuration.

 

Testing - Assign overlay "Bridge-Segment-VL10" to TestVM03 and assign IP from subnet range 10.89.208.0/27, which is nothing but the overlay subnet of NSX-v used for bridging with same VLAN-10.

TestVM03 - 10.89.208.5

Result - Able to ping 10.89.208.2 where network is connected to physical DPG VLAN10 & 10.89.208.1 where network is connected to NSX-v Overlay segment.

·       Remember we have not assigned any subnet to NSX-T overlay, but still we are able to assign IP from overlay subnet of NSX-v & ping with in the broadcast domain, all happening with L2Bridge.

 

 

 

 

 

 

Artifacts - Logged in to ESX where DLR resides to check on MAC address learning.

·       MAC of VM1 (connected to NSX-v Overlay) is being learnt via Overlay segment.

·       MAC of VM2 (connected to DPG/underlay) and VM3 (connected to NSX-T Overlay) are being learnt via VLAN segment.

  

PS: Improvement points or suggestions are welcome.

 

-----Thank You-----

Prashant Pandey