V to T Migration - Bridging Universal Logical Switches?

[HybridNetArchit]

Hi,

Approach for migrating from V to T is described as using either 'Migration coordinator' or 'in Parallel Migration. The former (a tool) is restricted in that it does not work with cross vCenter V deployments*, so thus leaving the 'In Parallel' approach.

Having a use case where Cross vCenter NSX is used, we were set on using the In Parallel approach, and based on the complexity of the environment  have looked and written up the approach to use Bridging, 'Independent Bridging' to be precise to allow multiple parallel bridged networks using V and T bridges as described in the approach. 

I have however just read something that has completely thrown me in an NSX for vSphere Bridging guide:

"You cannot use a universal distributed logical router to configure bridging, and you cannot add a bridge to a universal logical switch"

So the question is, If a customer is using cross vCenter NSX (in V), then they most likely using universal constructs (Universal Distributed Logical Router and Universal Logical Switches).  So how do VMware expect this parallel approach with bridging to actually work?

Can NSX-T only bridging work instead? (just have to deploy multiple edges), but this would mean that the NSX-T edges would need to support universal logical switches as the V side of the VXLAN to Geneve bridge.

Of course, away from Bridging, I could fall back to using an alternate approach such as L2 VPN (via NSX Itself).

Any help clarifying this and any ideas on using bridging are gratefully appreciated

Thanks in advance

*I know in recent NSX-T sw versions there has been some changes with Cross vCenter support, but this does not help the use case in which I am working with, also, Migration Coordinator is big bang, and the risk of this approach with a huge complicated environment is not going to work anyway

[shank89]

Have you thought about using a tool like HCX for network extension or using NSX-T edge bridging?

[dimyke]

You cannot use a universal distributed logical router to configure bridging, and you cannot add a bridge to a universal logical switch
=> That is indeed true, a bridge in NSX-V is created on a normal distributed logical router because the 'universal' objects are for cross v-center nsx-v purposes.

'So how do VMware expect this parallel approach with bridging to actually work?'
=> it seems to me they did not include an approach for universal objects whatsoever so it will not work. You could try to create a setup where a normal distributed logical router is connected to the universal and create a bridge on that one.
However, universal objects has covered a lot of dust in my brains so I am not sure anymore if that is an option.

That brings us to 'Can NSX-T only bridging work instead? (just have to deploy multiple edges), but this would mean that the NSX-T edges would need to support universal logical switches as the V side of the VXLAN to Geneve bridge.'
=> Yes it would work and no it does not mean that the edges need to support universal logical switches.
As far as I understand it, there is no communication on NSX level and there is no NSX 'logic' behind the solution. What will happen is that the VM traffic between NSX-V and -T will be sent to the -V host with the NSX-T bridge, where NSX-V will decapsulate the VXLAN packet, pass the packet on to the VM (the -T bridge) and then the -T bridge will encapsulate it in Geneve.
So this solution is just levering capabilities of the two products on how they work under the hood.

But this is my understanding of how VMware explains it. Their explanation is very very brief so this is my interpretation.

As mentioned before, you could also have a look at HCX to create a L2 bridge and to the planning and migration with the tool.

I hope that helps.

Kr
Dimitri

[HybridNetArchit]

Thanks, had discounted HCX due to licensing costs. Have used it for VMConAWS migrations though and a good tool.

NSX-T Bridges is one of the options, but as we need to stretch potentially up to 12 networks at a time, my understanding is that we would need to run a bridge per stretched network using T edges, so the resource footprint for all the edges is going to be prohibitive, and ridiculous if we introduce redundancy (potentially up to 24 medium edges).

[HybridNetArchit]

Thanks for the detailed reply and clarifying how T edges would work in conjunction with V Host

NSX-T Bridges is one of the options, but as we need to stretch potentially up to 12 networks at a time, my understanding is that we would need to run a bridge per stretched network using T edges, so the resource footprint for all the edges is going to be prohibitive, and ridiculous if we introduce redundancy (potentially up to 24 medium edges). I have not gone for using small edges as it is described as POC/Lab only, although I imagine it would probably ne fine and support the throughput required.

The other thought I had was using L2 VPN, 2 options:

1. T to V L2 L2VPN using IPSEC, so the T is server, V is the client and the V client would need to be configured using API.

2. Run a V L2VPN with both server and client in same hosting cluster (probably best on different hosts) and allow that to convert the ULS into VLANs locally and pick the VLANs up on a T Edge. Essentially the V L2VPN is acting as a bridge from XLAN to VLAN.

We have run loads of L2VPN in the past with V for migration projects so know how they work pretty well, this makes me familiar with using the second option, but seems a little clunky - but know it would work. 

Have discounted HCX due to licensing costs.

[dimyke]

You would indeed need 12 edges because you will connect every segment to the a NSX-T edge vnic (one segment per NSX-T edge).

You can always try with a small edge VM but it might impact performance. It will depends on what kind of bandwidth you need and how much traffic will go over this edge. I would say, give it a shot. See https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/installation/GUID-22F87CA8-01A9-4F2E-B7DB-93... for more info on sizing.
Why would you create all the edges at the same time anyway? You can migrate one segment at a time and remove/reconfigure the NSX-T edge once done.

However, your idea of having a L2VPN would also work (option 1). 
I'm not sure I would go for your 2nd option with L2VPN tho and if it does it seems like a long work-a-round 😄

Kr
Dimitri

[shank89]

What licence do you have? Are you entitled to HCX?

The network extension appliance allows you to extend 12 networks per appliance.

[HybridNetArchit]

@shank89 

"What licence do you have? Are you entitled to HCX?"

We are using equivalent to NSX-T on advanced in SPP. If we were using Ent Plus we could use.

[HybridNetArchit]

@dimyke 

Thanks for confirmation.

"Why would you create all the edges at the same time anyway? You can migrate one segment at a time and remove/reconfigure the NSX-T edge once done."

Complicated multi-tenanted customer, lots of ESGs, DLRs, DFW Policies with dynamic match criteria etc. So the migrate all nets associated with the tenant and do a final route cutover actually simplifies and de-risks the migration.