Namishksharma wrote:
Design option 1 - NSX standalone with SRM.
Design Option 2 - NSX universal with SRM.
question : 1 Does any on these designs have implications if DCI is OTV
question 2: If NSX runs on OTV .. it means double tagging is happening . It will increase overhead and could hammer application which could bear latency.
question 3: Is their any vmware document where OTV is supported from NSX as customer is asking for one .
If not greenfield, does the client already have a vCenter on each site ? Or only one vCenter to manage both sites ?
Big design implications of cross-vc (NSX "universal") :
- you can't use vCenter containers, objects or criterias in DFW and Security groups: must be IP/MAC based
- the redundancy of the NSX manager is kind of tricky, it can be done, but most of the failover / failback has to be done manually / scripted (switch to primary, redeploy controllers and control vms when failing over...)
The double tagging is handled in hardware with OTV (on Nexus anyway), so I wouldn't be too much concerned by the latency (a hit you'll have, but not so big). As long as you have the MTU, it should be OK... BUT, the real question is: why would you use an OTV-extended VLAN for encapsulating VXLAN transport ? this one can be routed. Just use two VXLAN transport vlans, one on each site, and route in between !
In the case of dual "standalone" NSX managers, and if you need to bridge between OTV-extended VLANs and VXLANs, just make sure you do that on only one site 😉
--
Helios le Guillou de Creisquer
